From owner-freebsd-net@FreeBSD.ORG Sun Apr 23 02:20:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4365B16A404; Sun, 23 Apr 2006 02:20:23 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from mx0.thekeelecentre.com (mx0.thekeelecentre.com [217.206.238.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFDF443D45; Sun, 23 Apr 2006 02:20:22 +0000 (GMT) (envelope-from richardtector@thekeelecentre.com) Received: from localhost (mailfil.mx0.thekeelecentre.com [217.206.238.165]) by mx0.thekeelecentre.com (Postfix) with ESMTP id BC14E4090; Sun, 23 Apr 2006 03:20:16 +0100 (BST) X-Virus-Scanned: by amavisd-new at mx0.thekeelecentre.com Received: from mx0.thekeelecentre.com ([217.206.238.167]) by localhost (mailfil.mx0.thekeelecentre.com [217.206.238.165]) (amavisd-new, port 10024) with ESMTP id c4FrtGuefK0v; Sun, 23 Apr 2006 03:20:05 +0100 (BST) Received: from webmail.thekeelecentre.com (webmail.thekeelecentre.com [217.206.238.169]) by mx0.thekeelecentre.com (Postfix) with ESMTP id BC97840C8; Sun, 23 Apr 2006 03:20:02 +0100 (BST) Received: from 217.206.238.131 ([217.206.238.131]) by webmail.thekeelecentre.com (Horde MIME library) with HTTP for ; Sun, 23 Apr 2006 03:20:02 +0100 Message-ID: <20060423032002.7yty36ga8so0w8o0@webmail.thekeelecentre.com> Date: Sun, 23 Apr 2006 03:20:02 +0100 From: Richard Tector To: Brooks Davis References: <170970070.20060112144241@kr.ru> <20060112105808.0ec94f40.lists@yazzy.org> <20060112101616.GG2332@heff.fud.org.nz> <20060112102309.25f2e33a.lists@yazzy.org> <20060112103126.GH2332@heff.fud.org.nz> <20060112192122.GA6660@odin.ac.hmc.edu> In-Reply-To: <20060112192122.GA6660@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) / FreeBSD-5.4 Cc: Marcin, freebsd-net@freebsd.org, Jessa , Andrew Thompson Subject: Re: Automatic VLANS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2006 02:20:23 -0000 Quoting Andrew Thompson : > On Thu, Jan 12, 2006 at 10:58:08AM +0100, Marcin Jessa wrote: >> On Thu, 12 Jan 2006 14:42:41 +0700 >> Vitaliy Ovsyannikov wrote: >> > Does Automatic VLANS works? >> > It is was described in >> > http://people.freebsd.org/~andre/FreeBSD-5.3-Networking.pdf >> > >> > # ifconfig em0.1 inet 10.90.90.200/24 >> > ifconfig: interface em0.1 does not exist > While what you have posted is correct, the automatic vlans the original > poster referred to do exist. 'ifconfig em0.1 create' will create a vlan > and also set the parent to em0 and tag as 1. > > Andrew Is it possible to use this method through rc or must I stick with creating vlan1, vlan2, vlan3, etc and setting the vlanid and vlandev since my attmpts have yielded no success. Eg. rc.conf: ifconfig_em0="up vlanhwtag vlanmtu" ifconfig_em0.100="inet 10.1.2.3/24" goliath# /etc/rc.d/netif start /etc/rc.conf: ifconfig_em0.100=inet 10.1.2.3/24: not found lo0: flags=8049 mtu 16384 .... and the interface is never created, with or without: cloned_interfaces="em0.100" Any suggestions? Regards, Richard Tector From owner-freebsd-net@FreeBSD.ORG Sun Apr 23 12:35:30 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EC5616A400 for ; Sun, 23 Apr 2006 12:35:30 +0000 (UTC) (envelope-from lerik@nolink.net) Received: from electra.nolink.net (electra.nolink.net [195.139.204.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8402D43D46 for ; Sun, 23 Apr 2006 12:35:29 +0000 (GMT) (envelope-from lerik@nolink.net) Received: (qmail 52986 invoked by uid 89); 23 Apr 2006 12:35:25 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by 127.0.0.1 with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Apr 2006 12:35:25 -0000 Date: Sun, 23 Apr 2006 14:35:24 +0200 (CEST) From: Lars Erik Gullerud To: freebsd-net@freebsd.org Message-ID: <20060423114810.P36951@electra.nolink.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Watchdog timeouts and dead network on bge - 6.1-RC1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2006 12:35:30 -0000 We recently upgraded one of our 4.11 servers to 6.1-RC1. The server is a Dell PE2650, dual Xeons, and has two onboard Broadcom BCM5701 cards, using the bge driver. Some older threads on -net and -current led me to believe that most issues with bge driver in FreeBSD >4 had been sorted. However, after our upgrade, we are seing errors like this: Apr 22 18:44:01 nebula kernel: bge0: watchdog timeout -- resetting Apr 22 18:44:01 nebula kernel: bge0: link state changed to DOWN Apr 22 18:44:03 nebula kernel: bge0: link state changed to UP ...and more importantly - when this happens, the network connection does NOT in fact come back up. Logging into the box locally (or via a different network interface) and manually issuing "ifconfig bge0 down ; ifconfig bge0 up" DOES get the interface going again, however. We have only seen this on very high network loads - the particular message included above occured while transferring some 120GB of data from a 4.11 NFS-server to this 6.1-RC1 box. Is this a known issue in bge? If so, is anyone working on it? Can we provide some useful information to whoever this might be? We have never had any issues with bge in 4.x, but we really need to get this server up to 5.x/6.x at this point in time, any other suggestions on knobs or workarounds that can give us bge stability? Thanks in advance, /leg From owner-freebsd-net@FreeBSD.ORG Sun Apr 23 12:41:53 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B56D116A401 for ; Sun, 23 Apr 2006 12:41:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FC3243D49 for ; Sun, 23 Apr 2006 12:41:53 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id DC22346C16; Sun, 23 Apr 2006 08:41:52 -0400 (EDT) Date: Sun, 23 Apr 2006 13:41:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Lars Erik Gullerud In-Reply-To: <20060423114810.P36951@electra.nolink.net> Message-ID: <20060423133913.T56433@fledge.watson.org> References: <20060423114810.P36951@electra.nolink.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Watchdog timeouts and dead network on bge - 6.1-RC1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2006 12:41:53 -0000 On Sun, 23 Apr 2006, Lars Erik Gullerud wrote: > We recently upgraded one of our 4.11 servers to 6.1-RC1. The server is a > Dell PE2650, dual Xeons, and has two onboard Broadcom BCM5701 cards, using > the bge driver. > > Some older threads on -net and -current led me to believe that most issues > with bge driver in FreeBSD >4 had been sorted. However, after our upgrade, > we are seing errors like this: There's a Dell 2650 in the FreeBSD netperf cluster. When working with 5.x on the box quite a long time ago, I saw similar problems, in which the network interface stalled and required kicking to reset. Unfortunately, this is not an issue I have time to work on currently, but if it would help a FreeBSD developer track down and debug this problem, I can provide remote access to a box that has had the problem in the past, along with serial console, remote power, and network booting. I'll run some tests on it today and see if that box still has the same problem or not. I've never been entirely convinced it was actually a bge problem as opposed to an interrupt delivery problem, however. Dmesg fragment below. Robert N M Watson Copyright (c) 1992-2005 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 6.0-CURRENT #1: Sat Jan 29 21:32:42 EST 2005 rwatson@zoo.freebsd.org:/usr/obj/zoo/rwatson/netperf/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) XEON(TM) CPU 2.20GHz (2192.90-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febfbff real memory = 2147352576 (2047 MB) avail memory = 2096799744 (1999 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic2: Changing APIC ID to 10 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard ioapic2 irqs 32-47 on motherboard ... ACPI APIC Table: acpi0: on motherboard aac0: mem 0xf0000000-0xf7ffffff irq 30 at device 8.1 on pci4 ... bge0: mem 0xfcd10000-0xfcd1ffff irq 28 at device 6.0 on pci3 miibus0: on bge0 bge0: Ethernet address: 00:06:5b:8e:b9:8d bge1: mem 0xfcd00000-0xfcd0ffff irq 29 at device 8.0 on pci3 miibus1: on bge1 bge1: Ethernet address: 00:06:5b:8e:b9:8e > > Apr 22 18:44:01 nebula kernel: bge0: watchdog timeout -- resetting > Apr 22 18:44:01 nebula kernel: bge0: link state changed to DOWN > Apr 22 18:44:03 nebula kernel: bge0: link state changed to UP > > ...and more importantly - when this happens, the network connection does NOT > in fact come back up. Logging into the box locally (or via a different > network interface) and manually issuing "ifconfig bge0 down ; ifconfig bge0 > up" DOES get the interface going again, however. > > We have only seen this on very high network loads - the particular message > included above occured while transferring some 120GB of data from a 4.11 > NFS-server to this 6.1-RC1 box. > > Is this a known issue in bge? If so, is anyone working on it? Can we provide > some useful information to whoever this might be? > > We have never had any issues with bge in 4.x, but we really need to get this > server up to 5.x/6.x at this point in time, any other suggestions on knobs or > workarounds that can give us bge stability? > > Thanks in advance, > > /leg > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sun Apr 23 12:51:56 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96B6B16A404 for ; Sun, 23 Apr 2006 12:51:56 +0000 (UTC) (envelope-from oxy@field.hu) Received: from green.field.hu (green.field.hu [217.20.130.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id C08F143D45 for ; Sun, 23 Apr 2006 12:51:55 +0000 (GMT) (envelope-from oxy@field.hu) Received: from localhost (green.field.hu [217.20.130.28]) by green.field.hu (Postfix) with ESMTP id 261B2119CD7 for ; Sun, 23 Apr 2006 14:49:44 +0200 (CEST) X-Virus-Scanned: by Amavisd-new (Spamassassin+Razor2+Pyzor+DCC+Bayes db, Clamd Antivirus) at field.hu Received: from green.field.hu ([217.20.130.28]) by localhost (green.field.hu [217.20.130.28]) (amavisd-new, port 10024) with ESMTP id rs0deb5gYY1X for ; Sun, 23 Apr 2006 14:49:43 +0200 (CEST) Received: from oxy (dsl85-238-76-93.pool.tvnet.hu [85.238.76.93]) by green.field.hu (Postfix) with ESMTP id CD163119CA0 for ; Sun, 23 Apr 2006 14:49:43 +0200 (CEST) Message-ID: <001201c666d4$b69dc290$0201a8c0@oxy> From: "OxY" To: Date: Sun, 23 Apr 2006 14:52:00 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Marvell 88E8053 lan controller support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2006 12:51:56 -0000 hi! my question is when will this chip being supported by 6.x? or is it supported now and i didn't find the proper driver? :) thanks From owner-freebsd-net@FreeBSD.ORG Sun Apr 23 14:10:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 933B616A409 for ; Sun, 23 Apr 2006 14:10:11 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 120F543D46 for ; Sun, 23 Apr 2006 14:10:10 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 80430200138; Sun, 23 Apr 2006 16:10:08 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 9A8DD200137; Sun, 23 Apr 2006 16:10:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id C94F3444F41; Sun, 23 Apr 2006 14:09:45 +0000 (UTC) Date: Sun, 23 Apr 2006 14:09:45 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: OxY In-Reply-To: <001201c666d4$b69dc290$0201a8c0@oxy> Message-ID: <20060423140833.V13011@maildrop.int.zabbadoz.net> References: <001201c666d4$b69dc290$0201a8c0@oxy> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-net@freebsd.org Subject: Re: Marvell 88E8053 lan controller support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2006 14:10:11 -0000 On Sun, 23 Apr 2006, OxY wrote: > hi! > > my question is when will this chip being supported by 6.x? for x>1 maybe. > or is it supported now and i didn't find the proper driver? :) search freebsd-net archive of Jan 2006, posting from andre oppermann and do not forget to read the follow-ups. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Sun Apr 23 18:44:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58B4416A401 for ; Sun, 23 Apr 2006 18:44:38 +0000 (UTC) (envelope-from oxy@field.hu) Received: from green.field.hu (green.field.hu [217.20.130.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3F7843D6A for ; Sun, 23 Apr 2006 18:44:34 +0000 (GMT) (envelope-from oxy@field.hu) Received: from localhost (green.field.hu [217.20.130.28]) by green.field.hu (Postfix) with ESMTP id 5B2AF119CD7; Sun, 23 Apr 2006 20:42:21 +0200 (CEST) X-Virus-Scanned: by Amavisd-new (Spamassassin+Razor2+Pyzor+DCC+Bayes db, Clamd Antivirus) at field.hu Received: from green.field.hu ([217.20.130.28]) by localhost (green.field.hu [217.20.130.28]) (amavisd-new, port 10024) with ESMTP id BaYkmlCmB1M2; Sun, 23 Apr 2006 20:42:21 +0200 (CEST) Received: from oxy (dsl85-238-76-93.pool.tvnet.hu [85.238.76.93]) by green.field.hu (Postfix) with ESMTP id 169B7119CA0; Sun, 23 Apr 2006 20:42:21 +0200 (CEST) Message-ID: <000a01c66705$fa7be9c0$0201a8c0@oxy> From: "OxY" To: "Bjoern A. Zeeb" References: <001201c666d4$b69dc290$0201a8c0@oxy> <20060423140833.V13011@maildrop.int.zabbadoz.net> Date: Sun, 23 Apr 2006 20:44:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Cc: freebsd-net@freebsd.org Subject: Re: Marvell 88E8053 lan controller support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2006 18:44:38 -0000 thank you, i will test it soon! ----- Original Message ----- From: "Bjoern A. Zeeb" To: "OxY" Cc: Sent: Sunday, April 23, 2006 4:09 PM Subject: Re: Marvell 88E8053 lan controller support > On Sun, 23 Apr 2006, OxY wrote: > >> hi! >> >> my question is when will this chip being supported by 6.x? > > for x>1 maybe. > >> or is it supported now and i didn't find the proper driver? :) > > search freebsd-net archive of Jan 2006, posting from andre oppermann > and do not forget to read the follow-ups. > > -- > Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Sun Apr 23 23:38:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F0DD16A402 for ; Sun, 23 Apr 2006 23:38:22 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF59B43D5D for ; Sun, 23 Apr 2006 23:38:18 +0000 (GMT) (envelope-from chrcoluk@gmail.com) Received: by pproxy.gmail.com with SMTP id t32so875973pyc for ; Sun, 23 Apr 2006 16:38:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SMrDwX5lhL6Q7BYlVUdyPkSQh0QsO+yzS+6+GL0UqfZyYQbdIzgPTgXtHhWcP3KjhbSzJ4S2a/F6cz2OPktwY0LFEPfR7nThc1QZXiPw2y/58irJTDusSI4hsq5y4lYsvrbtIpPVeBkE9zoZpRfAMBpNG0BJkw1X6OLC4MM6BcA= Received: by 10.35.100.6 with SMTP id c6mr66578pym; Sun, 23 Apr 2006 16:38:18 -0700 (PDT) Received: by 10.35.36.18 with HTTP; Sun, 23 Apr 2006 16:38:18 -0700 (PDT) Message-ID: <3aaaa3a0604231638x3ab6f471y770ae00b43eb7f56@mail.gmail.com> Date: Mon, 24 Apr 2006 00:38:18 +0100 From: Chris To: "Robert Watson" In-Reply-To: <20060423133913.T56433@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060423114810.P36951@electra.nolink.net> <20060423133913.T56433@fledge.watson.org> Cc: freebsd-net@freebsd.org, Lars Erik Gullerud Subject: Re: Watchdog timeouts and dead network on bge - 6.1-RC1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2006 23:38:22 -0000 On 23/04/06, Robert Watson wrote: > On Sun, 23 Apr 2006, Lars Erik Gullerud wrote: > > > We recently upgraded one of our 4.11 servers to 6.1-RC1. The server is = a > > Dell PE2650, dual Xeons, and has two onboard Broadcom BCM5701 cards, us= ing > > the bge driver. > > > > Some older threads on -net and -current led me to believe that most iss= ues > > with bge driver in FreeBSD >4 had been sorted. However, after our upgra= de, > > we are seing errors like this: > > There's a Dell 2650 in the FreeBSD netperf cluster. When working with 5.= x on > the box quite a long time ago, I saw similar problems, in which the netwo= rk > interface stalled and required kicking to reset. Unfortunately, this is = not > an issue I have time to work on currently, but if it would help a FreeBSD > developer track down and debug this problem, I can provide remote access = to a > box that has had the problem in the past, along with serial console, remo= te > power, and network booting. I'll run some tests on it today and see if t= hat > box still has the same problem or not. I've never been entirely convince= d it > was actually a bge problem as opposed to an interrupt delivery problem, > however. Dmesg fragment below. > > Robert N M Watson > > Copyright (c) 1992-2005 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 6.0-CURRENT #1: Sat Jan 29 21:32:42 EST 2005 > rwatson@zoo.freebsd.org:/usr/obj/zoo/rwatson/netperf/src/sys/GENERIC > WARNING: WITNESS option enabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) XEON(TM) CPU 2.20GHz (2192.90-MHz 686-class CPU) > Origin =3D "GenuineIntel" Id =3D 0xf24 Stepping =3D 4 > > Features=3D0x3febfbff > real memory =3D 2147352576 (2047 MB) > avail memory =3D 2096799744 (1999 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 6 > ioapic0: Changing APIC ID to 8 > ioapic1: Changing APIC ID to 9 > ioapic2: Changing APIC ID to 10 > MADT: Forcing active-low polarity and level trigger for SCI > ioapic0 irqs 0-15 on motherboard > ioapic1 irqs 16-31 on motherboard > ioapic2 irqs 32-47 on motherboard > ... > ACPI APIC Table: > acpi0: on motherboard > aac0: mem 0xf0000000-0xf7ffffff irq 30 at device 8.1 on = pci4 > ... > bge0: mem > 0xfcd10000-0xfcd1ffff irq 28 at device 6.0 on pci3 > miibus0: on bge0 > bge0: Ethernet address: 00:06:5b:8e:b9:8d > bge1: mem > 0xfcd00000-0xfcd0ffff irq 29 at device 8.0 on pci3 > miibus1: on bge1 > bge1: Ethernet address: 00:06:5b:8e:b9:8e > > > > > > Apr 22 18:44:01 nebula kernel: bge0: watchdog timeout -- resetting > > Apr 22 18:44:01 nebula kernel: bge0: link state changed to DOWN > > Apr 22 18:44:03 nebula kernel: bge0: link state changed to UP > > > > ...and more importantly - when this happens, the network connection doe= s NOT > > in fact come back up. Logging into the box locally (or via a different > > network interface) and manually issuing "ifconfig bge0 down ; ifconfig = bge0 > > up" DOES get the interface going again, however. > > > > We have only seen this on very high network loads - the particular mess= age > > included above occured while transferring some 120GB of data from a 4.1= 1 > > NFS-server to this 6.1-RC1 box. > > > > Is this a known issue in bge? If so, is anyone working on it? Can we pr= ovide > > some useful information to whoever this might be? > > > > We have never had any issues with bge in 4.x, but we really need to get= this > > server up to 5.x/6.x at this point in time, any other suggestions on kn= obs or > > workarounds that can give us bge stability? > > > > Thanks in advance, > > > > /leg > > _______________________________________________ I had this problem on a 6.0 RELEASE server but I got it to stop, the interface is bge0, the problem only occurs when the card is negotiated in 10mbit, when we switched back to 100mbit full duplex the problem went away, we also found that adding aliases with netmask 255.255.255.255 caused bge0 to switch between DOWN and UP, I got no watchdog errors but we had the DOWN/UP problem. The box needed a reboot to come back online again. Unfortenatly this isnt my server I just admin it for a client so I am not in a position to give access but I will speak to him and if he is ok with it I am happy to test patches etc. that may solve this problem. Chris From owner-freebsd-net@FreeBSD.ORG Mon Apr 24 05:08:13 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AE5C16A400; Mon, 24 Apr 2006 05:08:13 +0000 (UTC) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FB9043D4C; Mon, 24 Apr 2006 05:08:12 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k3O58B5V008617; Sun, 23 Apr 2006 22:08:11 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k3O58An4008616; Sun, 23 Apr 2006 22:08:10 -0700 Date: Sun, 23 Apr 2006 22:08:10 -0700 From: Brooks Davis To: Richard Tector Message-ID: <20060424050810.GB3499@odin.ac.hmc.edu> References: <170970070.20060112144241@kr.ru> <20060112105808.0ec94f40.lists@yazzy.org> <20060112101616.GG2332@heff.fud.org.nz> <20060112102309.25f2e33a.lists@yazzy.org> <20060112103126.GH2332@heff.fud.org.nz> <20060112192122.GA6660@odin.ac.hmc.edu> <20060423032002.7yty36ga8so0w8o0@webmail.thekeelecentre.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kXdP64Ggrk/fb43R" Content-Disposition: inline In-Reply-To: <20060423032002.7yty36ga8so0w8o0@webmail.thekeelecentre.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-net@freebsd.org, Marcin Jessa , Andrew Thompson Subject: Re: Automatic VLANS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 05:08:13 -0000 --kXdP64Ggrk/fb43R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 23, 2006 at 03:20:02AM +0100, Richard Tector wrote: > Quoting Andrew Thompson : >=20 > >On Thu, Jan 12, 2006 at 10:58:08AM +0100, Marcin Jessa wrote: > >>On Thu, 12 Jan 2006 14:42:41 +0700 > >>Vitaliy Ovsyannikov wrote: > >>> Does Automatic VLANS works? > >>> It is was described in > >>> http://people.freebsd.org/~andre/FreeBSD-5.3-Networking.pdf > >>> > >>> # ifconfig em0.1 inet 10.90.90.200/24 > >>> ifconfig: interface em0.1 does not exist >=20 >=20 >=20 > >While what you have posted is correct, the automatic vlans the original > >poster referred to do exist. 'ifconfig em0.1 create' will create a vlan > >and also set the parent to em0 and tag as 1. > > > >Andrew >=20 > Is it possible to use this method through rc or must I stick with creating > vlan1, vlan2, vlan3, etc and setting the vlanid and vlandev since my attm= pts > have yielded no success. >=20 > Eg. > rc.conf: > ifconfig_em0=3D"up vlanhwtag vlanmtu" > ifconfig_em0.100=3D"inet 10.1.2.3/24" Periods aren't valid in shell variable names so this won't work. Hense the error message below. > goliath# /etc/rc.d/netif start > /etc/rc.conf: ifconfig_em0.100=3Dinet 10.1.2.3/24: not found > lo0: flags=3D8049 mtu 16384 > .... >=20 > and the interface is never created, with or without: > cloned_interfaces=3D"em0.100" The cloned_interfaces entry is absolutly required. > Any suggestions? Try without invalid expressions in /etc/rc.conf :). -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --kXdP64Ggrk/fb43R Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFETF05XY6L6fI4GtQRAvKjAJwPVErAot57o4vYh97P7fvsYpTRwACfWow4 u5gdRaxHqHksNkjuFpnWEno= =pXoU -----END PGP SIGNATURE----- --kXdP64Ggrk/fb43R-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 24 10:50:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4E8C16A402 for ; Mon, 24 Apr 2006 10:50:58 +0000 (UTC) (envelope-from vladgalu@gmail.com) Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 502C943D46 for ; Mon, 24 Apr 2006 10:50:58 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by pproxy.gmail.com with SMTP id t32so975156pyc for ; Mon, 24 Apr 2006 03:50:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ZWDL2+DRHOJx215pAGzL8LXbx33hVHZoKzjH4VkExGNoRODgWaofm4zL1T5WANa9ESPr0RhoLkukJe5FvSEQF72ec4HQH0ouYFvqyzHPxFav7NN9QPS45TYwm3D9E5WPwmpQe+Jm2az7FqcrMaryOsqlf/wNglBSnS7wAuhHTkw= Received: by 10.35.34.20 with SMTP id m20mr714209pyj; Mon, 24 Apr 2006 03:50:57 -0700 (PDT) Received: by 10.35.38.9 with HTTP; Mon, 24 Apr 2006 03:50:57 -0700 (PDT) Message-ID: <79722fad0604240350g602a175al59a926c9ddde9176@mail.gmail.com> Date: Mon, 24 Apr 2006 13:50:57 +0300 From: "Vlad GALU" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: requests for mbufs denied X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 10:50:58 -0000 The machine in question is a 6.1-RC. It serves a quite big number of clients (the lowest concurrency figures are around 2000, with peaks up to 9000). The in/out buffers for tcp sockets are 8K each. kern.ipc.nmbclusters is set to 327680. The firewall is pf, with the following limits: 131072 states and 262144 src-nodes. So more than generous limits. However, $subj statistics keep growing and growing. The machine has rebooted a few times, without dumping any core upon restart, although debugging support (both symbols and kgdb) is compiled in. Should I worry about the aforementioned stats ? If so, any idea of how to narrow the issue down ? I can't test much on the machine, unfortunately. P.S. I've the feeling that the growth rate of allocation failures went downhill since I removed the pfsync support, but it's just a feeling, I didn't measure it accurately. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Mon Apr 24 10:53:30 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F3AD16A401 for ; Mon, 24 Apr 2006 10:53:30 +0000 (UTC) (envelope-from vladgalu@gmail.com) Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBDF043D73 for ; Mon, 24 Apr 2006 10:53:23 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by pproxy.gmail.com with SMTP id t32so975734pyc for ; Mon, 24 Apr 2006 03:53:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jncqpp9NfoPQFz86r5fsmG3P87Wa4iG5Rsd91LgJuftajsglNEcBzqSsSkzbKx4OOmTrPva6by0AVFPJrsmblFsO0FSnQcZT1n78obunnpsY0MDTB/H0b7fA3laj/STkPzxTy5GWvuhW1FdUShj731NDHckgAbgAYbaCOhtdpRk= Received: by 10.35.66.12 with SMTP id t12mr792905pyk; Mon, 24 Apr 2006 03:53:22 -0700 (PDT) Received: by 10.35.38.9 with HTTP; Mon, 24 Apr 2006 03:53:22 -0700 (PDT) Message-ID: <79722fad0604240353x6b7d38feoc7dccc7b8662c486@mail.gmail.com> Date: Mon, 24 Apr 2006 13:53:22 +0300 From: "Vlad GALU" To: freebsd-net@freebsd.org In-Reply-To: <79722fad0604240350g602a175al59a926c9ddde9176@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <79722fad0604240350g602a175al59a926c9ddde9176@mail.gmail.com> Subject: Re: requests for mbufs denied X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 10:53:30 -0000 On 4/24/06, Vlad GALU wrote: > The machine in question is a 6.1-RC. It serves a quite big number > of clients (the lowest concurrency figures are around 2000, with peaks > up to 9000). The in/out buffers for tcp sockets are 8K each. > kern.ipc.nmbclusters is set to 327680. The firewall is pf, with the > following limits: 131072 states and 262144 src-nodes. So more than > generous limits. However, $subj statistics keep growing and growing. > The machine has rebooted a few times, without dumping any core upon > restart, although debugging support (both symbols and kgdb) is > compiled in. > Should I worry about the aforementioned stats ? If so, any idea of > how to narrow the issue down ? I can't test much on the machine, > unfortunately. > > P.S. I've the feeling that the growth rate of allocation failures went > downhill since I removed the pfsync support, but it's just a feeling, > I didn't measure it accurately. > As a secondary footnote, the statistics for the currenty used mbuf are never alarming, while the number of allocation request still grows: -- cut here -- 761/2314/3075 mbufs in use (current/cache/total) 406/568/974/327680 mbuf clusters in use (current/cache/total/max) [...] 1004K/1714K/2719K bytes allocated to network (current/cache/total) 273341/8477/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) -- and here -- > -- > If it's there, and you can see it, it's real. > If it's not there, and you can see it, it's virtual. > If it's there, and you can't see it, it's transparent. > If it's not there, and you can't see it, you erased it. > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Mon Apr 24 11:02:57 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53D8116A405 for ; Mon, 24 Apr 2006 11:02:57 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C66043D64 for ; Mon, 24 Apr 2006 11:02:50 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k3OB2o66035559 for ; Mon, 24 Apr 2006 11:02:50 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k3OB2n5Y035553 for freebsd-net@freebsd.org; Mon, 24 Apr 2006 11:02:49 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 24 Apr 2006 11:02:49 GMT Message-Id: <200604241102.k3OB2n5Y035553@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 11:02:57 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2006/01/30] kern/92552 net A serious bug in most network drivers fro f [2006/02/12] kern/93220 net [inet6] nd6_lookup: failed to add route f 2 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit o [2006/04/03] kern/95267 net packet drops periodically appear 2 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 24 11:18:52 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2889216A419 for ; Mon, 24 Apr 2006 11:18:52 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from mx0.thekeelecentre.com (mx0.thekeelecentre.com [217.206.238.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id A028943D45 for ; Mon, 24 Apr 2006 11:18:51 +0000 (GMT) (envelope-from richardtector@thekeelecentre.com) Received: from localhost (mailfil.mx0.thekeelecentre.com [217.206.238.165]) by mx0.thekeelecentre.com (Postfix) with ESMTP id 8FE304088; Mon, 24 Apr 2006 12:28:38 +0100 (BST) X-Virus-Scanned: by amavisd-new at mx0.thekeelecentre.com Received: from mx0.thekeelecentre.com ([217.206.238.167]) by localhost (mailfil.mx0.thekeelecentre.com [217.206.238.165]) (amavisd-new, port 10024) with ESMTP id HSqJ3cQ4jOmZ; Mon, 24 Apr 2006 12:28:27 +0100 (BST) Received: from [217.206.238.190] (host-190.thekeelecentre.com [217.206.238.190]) by mx0.thekeelecentre.com (Postfix) with ESMTP id 9E53C40BB; Mon, 24 Apr 2006 12:28:25 +0100 (BST) Message-ID: <444CB489.30802@thekeelecentre.com> Date: Mon, 24 Apr 2006 12:20:41 +0100 From: Richard Tector User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Brooks Davis References: <170970070.20060112144241@kr.ru> <20060112105808.0ec94f40.lists@yazzy.org> <20060112101616.GG2332@heff.fud.org.nz> <20060112102309.25f2e33a.lists@yazzy.org> <20060112103126.GH2332@heff.fud.org.nz> <20060112192122.GA6660@odin.ac.hmc.edu> <20060423032002.7yty36ga8so0w8o0@webmail.thekeelecentre.com> <20060424050810.GB3499@odin.ac.hmc.edu> In-Reply-To: <20060424050810.GB3499@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Automatic VLANS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 11:18:52 -0000 Brooks Davis wrote: > On Sun, Apr 23, 2006 at 03:20:02AM +0100, Richard Tector wrote: > >> Is it possible to use this method through rc or must I stick with creating >> vlan1, vlan2, vlan3, etc and setting the vlanid and vlandev since my attmpts >> have yielded no success. >> >> Eg. >> rc.conf: >> ifconfig_em0="up vlanhwtag vlanmtu" >> ifconfig_em0.100="inet 10.1.2.3/24" >> > > Periods aren't valid in shell variable names so this won't work. Hense > the error message below. > > >> goliath# /etc/rc.d/netif start >> /etc/rc.conf: ifconfig_em0.100=inet 10.1.2.3/24: not found >> lo0: flags=8049 mtu 16384 >> .... >> >> and the interface is never created, with or without: >> cloned_interfaces="em0.100" >> > > The cloned_interfaces entry is absolutly required. > Fair enough. I noticed you made a way to use the automatic vlan method in rev 1.169 of network.subr. Are there any plans to MFC this to RELENG_6? It's a useful ability to have and makes creating vlans at startup much simpler and cleaner. Regards, Richard Tector From owner-freebsd-net@FreeBSD.ORG Mon Apr 24 12:47:40 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B65216A400 for ; Mon, 24 Apr 2006 12:47:40 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 362F043D46 for ; Mon, 24 Apr 2006 12:47:38 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.4/8.13.4) with ESMTP id k3OClbsS072749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Apr 2006 16:47:37 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.4/8.13.4/Submit) id k3OClaN0072748; Mon, 24 Apr 2006 16:47:36 +0400 (MSD) (envelope-from oleg) Date: Mon, 24 Apr 2006 16:47:36 +0400 From: Oleg Bulyzhin To: Lars Erik Gullerud Message-ID: <20060424124736.GA72623@lath.rinet.ru> References: <20060423114810.P36951@electra.nolink.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h" Content-Disposition: inline In-Reply-To: <20060423114810.P36951@electra.nolink.net> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org Subject: Re: Watchdog timeouts and dead network on bge - 6.1-RC1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 12:47:40 -0000 --K8nIJk4ghYZn606h Content-Type: multipart/mixed; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 23, 2006 at 02:35:24PM +0200, Lars Erik Gullerud wrote: > We recently upgraded one of our 4.11 servers to 6.1-RC1. The server is a= =20 > Dell PE2650, dual Xeons, and has two onboard Broadcom BCM5701 cards, usin= g=20 > the bge driver. >=20 > Some older threads on -net and -current led me to believe that most issue= s=20 > with bge driver in FreeBSD >4 had been sorted. However, after our upgrade= ,=20 > we are seing errors like this: >=20 > Apr 22 18:44:01 nebula kernel: bge0: watchdog timeout -- resetting > Apr 22 18:44:01 nebula kernel: bge0: link state changed to DOWN > Apr 22 18:44:03 nebula kernel: bge0: link state changed to UP >=20 > ...and more importantly - when this happens, the network connection does= =20 > NOT in fact come back up. Logging into the box locally (or via a differen= t=20 > network interface) and manually issuing "ifconfig bge0 down ; ifconfig=20 > bge0 up" DOES get the interface going again, however. >=20 > We have only seen this on very high network loads - the particular messag= e=20 > included above occured while transferring some 120GB of data from a 4.11= =20 > NFS-server to this 6.1-RC1 box. >=20 > Is this a known issue in bge? If so, is anyone working on it? Can we=20 > provide some useful information to whoever this might be? >=20 > We have never had any issues with bge in 4.x, but we really need to get= =20 > this server up to 5.x/6.x at this point in time, any other suggestions on= =20 > knobs or workarounds that can give us bge stability? >=20 > Thanks in advance, >=20 > /leg > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" Could you try attached patch? It should fix problem when link goes UP but network is still down. About bge resets: you should try if_bge.c rev.1.126, it may help. P.S. anyway, please report how is it going. --=20 Oleg. --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bge_init_intr.diff" Content-Transfer-Encoding: quoted-printable Index: if_bge.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.91.2.13 diff -u -r1.91.2.13 if_bge.c --- if_bge.c 4 Mar 2006 09:34:48 -0000 1.91.2.13 +++ if_bge.c 17 Apr 2006 19:39:15 -0000 @@ -3308,6 +3308,14 @@ =09 bge_ifmedia_upd(ifp); =20 + sc->bge_link_evt++; +#ifdef DEVICE_POLLING + if (!(sc->bge_ifp->if_capenable & IFCAP_POLLING)) +#endif + { + BGE_SETBIT(sc, BGE_MISC_LOCAL_CTL, BGE_MLC_INTR_SET); + } + ifp->if_drv_flags |=3D IFF_DRV_RUNNING; ifp->if_drv_flags &=3D ~IFF_DRV_OACTIVE; =20 --17pEHd4RhPHOinZp-- --K8nIJk4ghYZn606h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFETMjoryLc73jOEF8RAtiKAJ9pIMnO2PurXk2R56rXPQiHPV7TLgCeLrnQ cGozrySFhNa1bLL1J5sD2/Q= =Wr6Y -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 24 13:30:07 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2A5E16A406 for ; Mon, 24 Apr 2006 13:30:07 +0000 (UTC) (envelope-from ferdinand.goldmann@jku.at) Received: from emailsecure.uni-linz.ac.at (emailsecure.uni-linz.ac.at [140.78.3.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id C012243D6A for ; Mon, 24 Apr 2006 13:30:04 +0000 (GMT) (envelope-from ferdinand.goldmann@jku.at) Received: from [140.78.164.13] (jku006048.edvz.uni-linz.ac.at [140.78.6.48]) by emailsecure.uni-linz.ac.at (Postfix) with ESMTP id 1D7FE22802C for ; Mon, 24 Apr 2006 15:30:02 +0200 (CEST) Message-ID: <444CD2D0.50800@jku.at> Date: Mon, 24 Apr 2006 15:29:52 +0200 From: Ferdinand Goldmann Organization: Johannes Kepler University User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: How to change order of NICs in FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ferdinand.goldmann@jku.at List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 13:30:07 -0000 Hi there, this might be an easy one, but I seem to be unable to come up with a google'd solution. :( I have a machine with four network cards using the em driver: em0@pci2:12:0: class=0x020000 card=0x10028086 chip=0x10268086 rev=0x04 hdr=0x00 em1@pci3:11:0: class=0x020000 card=0x10028086 chip=0x10268086 rev=0x04 hdr=0x00 em2@pci6:7:0: class=0x020000 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 em3@pci7:8:0: class=0x020000 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 Two of the cards are onboard, namely em2 and em3, and the other two (em0, em1) are sitting in expansion slots. I would like to change the order of the cards, so that the onboard cards are recognized as em0 and em1. I tried using the device.hints file, but without much success. Is there any way how to do this? Kind regards -- >> Ferdinand Goldmann //// | | >> |--00 | UNIX | >> Tel. : +43/732/2468/9398 Fax. : +43/732/2468/9397 C ^ | | >> EMail: Ferdinand.Goldmann@zid.uni-linz.ac.at \ ~/ ~~~|~~~~~~~~ >> PGP D4CF 8AA4 4B2A 7B88 65CA 5EDC 0A9B FA9A 13EA B993| |-----3 From owner-freebsd-net@FreeBSD.ORG Mon Apr 24 13:50:40 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B377016A48F for ; Mon, 24 Apr 2006 13:50:40 +0000 (UTC) (envelope-from erikt@owl.midgard.homeip.net) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id D545443D48 for ; Mon, 24 Apr 2006 13:50:39 +0000 (GMT) (envelope-from erikt@owl.midgard.homeip.net) Received: from falcon.midgard.homeip.net (83.253.29.241) by pne-smtpout2-sn2.hy.skanova.net (7.2.070) id 444497C500180038 for freebsd-net@freebsd.org; Mon, 24 Apr 2006 15:50:39 +0200 Received: (qmail 82265 invoked from network); 24 Apr 2006 15:50:39 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with SMTP; 24 Apr 2006 15:50:39 +0200 Received: (qmail 74523 invoked by uid 1001); 24 Apr 2006 15:50:38 +0200 Date: Mon, 24 Apr 2006 15:50:38 +0200 From: Erik Trulsson To: Ferdinand Goldmann Message-ID: <20060424135038.GA74444@owl.midgard.homeip.net> Mail-Followup-To: Ferdinand Goldmann , freebsd-net@freebsd.org References: <444CD2D0.50800@jku.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <444CD2D0.50800@jku.at> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org Subject: Re: How to change order of NICs in FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 13:50:40 -0000 On Mon, Apr 24, 2006 at 03:29:52PM +0200, Ferdinand Goldmann wrote: > Hi there, > > this might be an easy one, but I seem to be unable to come up with a google'd > solution. :( > > I have a machine with four network cards using the em driver: > > em0@pci2:12:0: class=0x020000 card=0x10028086 chip=0x10268086 rev=0x04 hdr=0x00 > em1@pci3:11:0: class=0x020000 card=0x10028086 chip=0x10268086 rev=0x04 hdr=0x00 > em2@pci6:7:0: class=0x020000 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 > em3@pci7:8:0: class=0x020000 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 > > Two of the cards are onboard, namely em2 and em3, and the other two (em0, em1) > are sitting in expansion slots. I would like to change the order of the cards, > so that the onboard cards are recognized as em0 and em1. > > I tried using the device.hints file, but without much success. Is there any > way how to do this? > I don't think there is any way to change in what order the kernel detects and configures them, but it is possible to rename the interfaces somewhat later in the boot process. You could try using the 'name' option to ifconfig(8). I believe the syntax is: ifconfig [oldifname] name [newifname] This can also be done via /etc/rc.conf. Read the the section on network_interfaces in the manpage for rc.conf(5) for syntax. You will probably have a minor problem if you wish to rename {em2, em3} to {em0, em1} while at the same time renaming the original {em0,em1} to {em2,em3} but that should be easily resolved using temporary names. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-net@FreeBSD.ORG Mon Apr 24 14:51:49 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80B7E16A406 for ; Mon, 24 Apr 2006 14:51:49 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9DCC43D6B for ; Mon, 24 Apr 2006 14:51:42 +0000 (GMT) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1FY2PN-0005E5-7U for freebsd-net@freebsd.org; Mon, 24 Apr 2006 16:51:25 +0200 Received: from mulder.f5.com ([205.229.151.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Apr 2006 16:51:25 +0200 Received: from atkin901 by mulder.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Apr 2006 16:51:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: othermark Date: Mon, 24 Apr 2006 07:51:05 -0700 Lines: 27 Message-ID: References: <001201c666d4$b69dc290$0201a8c0@oxy> <20060423140833.V13011@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mulder.f5.com User-Agent: KNode/0.10.2 Sender: news Subject: Re: Marvell 88E8053 lan controller support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 14:51:49 -0000 Bjoern A. Zeeb wrote: > On Sun, 23 Apr 2006, OxY wrote: > >> hi! >> >> my question is when will this chip being supported by 6.x? > > for x>1 maybe. > >> or is it supported now and i didn't find the proper driver? :) > > search freebsd-net archive of Jan 2006, posting from andre oppermann > and do not forget to read the follow-ups. Just so other people don't have to do the rummaging, here's the link from gmane.org. http://thread.gmane.org/gmane.os.freebsd.current/79126/focus=79126 I too am hoping someone will step up to the plate and this support will be integrated into -current. -- othermark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired); From owner-freebsd-net@FreeBSD.ORG Mon Apr 24 15:47:25 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD9FF16A400 for ; Mon, 24 Apr 2006 15:47:25 +0000 (UTC) (envelope-from lk@tempest.sk) Received: from proxy.dgrp.sk (proxy.dgrp.sk [195.28.127.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F87F43D49 for ; Mon, 24 Apr 2006 15:47:24 +0000 (GMT) (envelope-from lk@tempest.sk) Received: by proxy.dgrp.sk (Postfix, from userid 1003) id 2EDB7800B; Mon, 24 Apr 2006 17:47:23 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on proxy.dgrp.sk X-Spam-Level: X-Spam-Status: No, score=0.1 required=4.0 tests=AWL autolearn=ham version=3.1.0 Received: from webmail.tempest.sk (domino1.tempest.sk [195.28.100.38]) by proxy.dgrp.sk (Postfix) with ESMTP id 35A998007 for ; Mon, 24 Apr 2006 17:47:16 +0200 (CEST) Received: from lk107.tempest.sk ([195.28.109.37]) by webmail.tempest.sk (Lotus Domino Release 6.5.4) with ESMTP id 2006042417471294-17413 ; Mon, 24 Apr 2006 17:47:12 +0200 Received: from lk107.tempest.sk (localhost [127.0.0.1]) by lk107.tempest.sk (8.13.4/8.13.4) with ESMTP id k3OFl5Rw037112 for ; Mon, 24 Apr 2006 17:47:05 +0200 (CEST) (envelope-from lk@lk107.tempest.sk) Received: (from koren@localhost) by lk107.tempest.sk (8.13.4/8.13.1/Submit) id k3OFl5E8037109; Mon, 24 Apr 2006 17:47:05 +0200 (CEST) (envelope-from lk) X-Authentication-Warning: lk107.tempest.sk: koren set sender to lk using -f Sender: lk@tempest.sk To: freebsd-net@freebsd.org From: Ludovit Koren Date: 24 Apr 2006 17:47:05 +0200 Message-ID: <87k69f0ydi.fsf@lk107.tempest.sk> Lines: 15 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on Domino1/DGRP(Release 6.5.4|March 27, 2005) at 24.04.2006 17:47:13, Serialize by Router on Domino1/DGRP(Release 6.5.4|March 27, 2005) at 24.04.2006 17:47:16, Serialize complete at 24.04.2006 17:47:16 Content-Type: text/plain; charset=us-ascii Subject: Routes for interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 15:47:26 -0000 Hi, is there any possibility to set the routing statically on a multi-homed host so, that the packet is sent back via the same interface, as it has came from? Something like more default routes (it is not good name for it, I hope you can understand what I mean), depending on particular interface. Thanks. Regards, lk From owner-freebsd-net@FreeBSD.ORG Mon Apr 24 16:08:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F02FB16A407 for ; Mon, 24 Apr 2006 16:08:19 +0000 (UTC) (envelope-from joe@joeholden.co.uk) Received: from elise.stf.rewt.org.uk (elise.stf.rewt.org.uk [82.152.108.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0D4743D45 for ; Mon, 24 Apr 2006 16:08:17 +0000 (GMT) (envelope-from joe@joeholden.co.uk) Received: from [82.152.108.166] (im.a.raver.not.a.fucking.drug-addict.be [82.152.108.166]) (authenticated bits=0) by elise.stf.rewt.org.uk (8.13.6/8.13.4) with ESMTP id k3OG86jO021592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Apr 2006 17:08:09 +0100 (BST) (envelope-from joe@joeholden.co.uk) Message-ID: <444CF7E5.7030209@joeholden.co.uk> Date: Mon, 24 Apr 2006 17:08:05 +0100 From: Joe Holden User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Ludovit Koren References: <87k69f0ydi.fsf@lk107.tempest.sk> In-Reply-To: <87k69f0ydi.fsf@lk107.tempest.sk> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=13A6D1E7; url=http://www.joeholden.co.uk/pubkey.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD65881EA323E2347900567EF" X-Spam-Status: No, score=-1.3 required=3.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on elise.stf.rewt.org.uk Cc: freebsd-net@freebsd.org Subject: Re: Routes for interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joe@joeholden.co.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 16:08:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD65881EA323E2347900567EF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ludovit Koren wrote: >=20 > Hi, >=20 > is there any possibility to set the routing statically on a multi-homed= > host so, that the packet is sent back via the same interface, as it has= > came from? Something like more default routes (it is not good name for > it, I hope you can understand what I mean), depending on particular > interface. >=20 >=20 > Thanks. >=20 > Regards, > lk > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" You could probably achieve this using IPFW FWD (this is how I achieve something similiar). Either using ipfw fwd $GW1 ip from any to any via $INT1, or using an ip range, ie; ipfw fwd $GW2 ip from 1.2.3.4/24 to any or something. Thanks, Joe Holden finger joe@joeholden.co.uk --------------enigD65881EA323E2347900567EF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFETPfldQJXshOm0ecRAi8CAKCC/Yo+Sr7JgHajZF9Q/2jQ0/gOZgCfRJU3 76YHVDzfeFohC/vPoioPX6w= =aBd5 -----END PGP SIGNATURE----- --------------enigD65881EA323E2347900567EF-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 24 16:46:35 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9A7316A400 for ; Mon, 24 Apr 2006 16:46:35 +0000 (UTC) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id E715B43D46 for ; Mon, 24 Apr 2006 16:46:34 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k3OGkY3n012000; Mon, 24 Apr 2006 09:46:34 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k3OGkXvt011999; Mon, 24 Apr 2006 09:46:33 -0700 Date: Mon, 24 Apr 2006 09:46:33 -0700 From: Brooks Davis To: Richard Tector Message-ID: <20060424164633.GA11053@odin.ac.hmc.edu> References: <170970070.20060112144241@kr.ru> <20060112105808.0ec94f40.lists@yazzy.org> <20060112101616.GG2332@heff.fud.org.nz> <20060112102309.25f2e33a.lists@yazzy.org> <20060112103126.GH2332@heff.fud.org.nz> <20060112192122.GA6660@odin.ac.hmc.edu> <20060423032002.7yty36ga8so0w8o0@webmail.thekeelecentre.com> <20060424050810.GB3499@odin.ac.hmc.edu> <444CB489.30802@thekeelecentre.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: <444CB489.30802@thekeelecentre.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-net@freebsd.org Subject: Re: Automatic VLANS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 16:46:35 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 24, 2006 at 12:20:41PM +0100, Richard Tector wrote: > Brooks Davis wrote: > >On Sun, Apr 23, 2006 at 03:20:02AM +0100, Richard Tector wrote: > > =20 > >>Is it possible to use this method through rc or must I stick with creat= ing > >>vlan1, vlan2, vlan3, etc and setting the vlanid and vlandev since my=20 > >>attmpts > >>have yielded no success. > >> > >>Eg. > >>rc.conf: > >>ifconfig_em0=3D"up vlanhwtag vlanmtu" > >>ifconfig_em0.100=3D"inet 10.1.2.3/24" > >> =20 > > > >Periods aren't valid in shell variable names so this won't work. Hense > >the error message below. > > > > =20 > >>goliath# /etc/rc.d/netif start > >>/etc/rc.conf: ifconfig_em0.100=3Dinet 10.1.2.3/24: not found > >>lo0: flags=3D8049 mtu 16384 > >>.... > >> > >>and the interface is never created, with or without: > >>cloned_interfaces=3D"em0.100" > >> =20 > > > >The cloned_interfaces entry is absolutly required. > > =20 > Fair enough. >=20 > I noticed you made a way to use the automatic vlan method in rev 1.169=20 > of network.subr. Are there any plans to MFC this to RELENG_6? It's a=20 > useful ability to have and makes creating vlans at startup much simpler= =20 > and cleaner. Yes, after 6.1 ships. It's way to late to be mucking around in the interface config scripts for 6.1-RELEASE. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFETQDpXY6L6fI4GtQRAr5mAJ99v5JdVkdOYIWBTwydPxmTOJEiTgCeL+vm LNQM68YMGsJOHWy39udWsn0= =Fk0n -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 24 23:49:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0D8716A402 for ; Mon, 24 Apr 2006 23:49:58 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8DEB43D66 for ; Mon, 24 Apr 2006 23:49:48 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by nz-out-0102.google.com with SMTP id i28so1020621nzi for ; Mon, 24 Apr 2006 16:49:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=Irdgz3pQR+qB7bjoVS5C1udcu/arcyckAdtCV27VHfWzswLeGNidkqEM3rUEk4BZ11hDiMfvwJmAI4bm/HQ7hJzyeD06TAGOapACBKUsr5AydrdxyzGVrmUiEM73DwNXt1mnb/lgb6u92er+rpWrQpM6t1XioFJknTxLB4E+J4g= Received: by 10.37.12.23 with SMTP id p23mr1000354nzi; Mon, 24 Apr 2006 16:49:48 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 15sm646427nzo.2006.04.24.16.49.46; Mon, 24 Apr 2006 16:49:47 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k3ONnZ9u001127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Apr 2006 08:49:35 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k3ONnY9n001126; Tue, 25 Apr 2006 08:49:34 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 25 Apr 2006 08:49:34 +0900 From: Pyun YongHyeon To: othermark Message-ID: <20060424234934.GA946@cdnetworks.co.kr> References: <001201c666d4$b69dc290$0201a8c0@oxy> <20060423140833.V13011@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: Marvell 88E8053 lan controller support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 23:49:58 -0000 On Mon, Apr 24, 2006 at 07:51:05AM -0700, othermark wrote: > Bjoern A. Zeeb wrote: > > > On Sun, 23 Apr 2006, OxY wrote: > > > >> hi! > >> > >> my question is when will this chip being supported by 6.x? > > > > for x>1 maybe. > > > >> or is it supported now and i didn't find the proper driver? :) > > > > search freebsd-net archive of Jan 2006, posting from andre oppermann > > and do not forget to read the follow-ups. > > Just so other people don't have to do the rummaging, here's the link from > gmane.org. > > http://thread.gmane.org/gmane.os.freebsd.current/79126/focus=79126 > > I too am hoping someone will step up to the plate and this support will be > integrated into -current. > I've tried their driver on CURRENT(It needs a minor modification to compile on CURRENT). But the driver didn't recognize link and even it panicked with numeros witness warnings when I enabled jumbo frame support. In addition it didn't attach for DGE530T. I think there driver is in experimental stage not for production use. In order to support Yukon II we need a documentation from Marvell. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Tue Apr 25 00:01:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FC4C16A405 for ; Tue, 25 Apr 2006 00:01:09 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from mail.comstyle.com (toronto-hs-216-138-195-228.s-ip.magma.ca [216.138.195.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E97743D46 for ; Tue, 25 Apr 2006 00:01:08 +0000 (GMT) (envelope-from brad@comstyle.com) Received: from blar.home.comstyle.com (blar.home.comstyle.com [IPv6:2001:240:589:1::3]) by fubar.home.comstyle.com (Postfix) with ESMTP id 568ACA3A5E for ; Mon, 24 Apr 2006 20:01:07 -0400 (EDT) Received: by blar.home.comstyle.com (Postfix, from userid 1000) id A93FDD3718; Mon, 24 Apr 2006 20:01:06 -0400 (EDT) Date: Mon, 24 Apr 2006 20:01:06 -0400 From: Brad To: freebsd-net@freebsd.org Message-ID: <20060425000106.GF14517@blar.home.comstyle.com> References: <001201c666d4$b69dc290$0201a8c0@oxy> <20060423140833.V13011@maildrop.int.zabbadoz.net> <20060424234934.GA946@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060424234934.GA946@cdnetworks.co.kr> User-Agent: Mutt/1.4.2i Subject: Re: Marvell 88E8053 lan controller support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 00:01:09 -0000 On Tue, Apr 25, 2006 at 08:49:34AM +0900, Pyun YongHyeon wrote: > On Mon, Apr 24, 2006 at 07:51:05AM -0700, othermark wrote: > > Bjoern A. Zeeb wrote: > > > > > On Sun, 23 Apr 2006, OxY wrote: > > > > > >> hi! > > >> > > >> my question is when will this chip being supported by 6.x? > > > > > > for x>1 maybe. > > > > > >> or is it supported now and i didn't find the proper driver? :) > > > > > > search freebsd-net archive of Jan 2006, posting from andre oppermann > > > and do not forget to read the follow-ups. > > > > Just so other people don't have to do the rummaging, here's the link from > > gmane.org. > > > > http://thread.gmane.org/gmane.os.freebsd.current/79126/focus=79126 > > > > I too am hoping someone will step up to the plate and this support will be > > integrated into -current. > > > > I've tried their driver on CURRENT(It needs a minor modification to > compile on CURRENT). But the driver didn't recognize link and even > it panicked with numeros witness warnings when I enabled jumbo frame > support. > In addition it didn't attach for DGE530T. I think there driver is > in experimental stage not for production use. In order to support > Yukon II we need a documentation from Marvell. It is *extremely* unlikely that you will ever see documentation for the Yukon II from Marvell. At this point the only option is to reverse engineer the existing driver and/or use the new Linux driver as a source of information. From owner-freebsd-net@FreeBSD.ORG Tue Apr 25 00:19:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FA5E16A404 for ; Tue, 25 Apr 2006 00:19:12 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id B80E443D53 for ; Tue, 25 Apr 2006 00:19:05 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by nz-out-0102.google.com with SMTP id i28so1024481nzi for ; Mon, 24 Apr 2006 17:19:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=LuCp109rmYc+UiL9PuYA6/hb9dxF4IKETz5knfukxdrKz0BVvECnVvbi6kpoAWkXMD+vzJ+/tNS3odVValO4t9OhKRzjga+8QpuKWrZ8CzGnjgLdX26q99gLMY9MCPhN46AbCT0YNWFqcgseIovqX10hQse2PtHPJRwcjKr5AMU= Received: by 10.36.247.12 with SMTP id u12mr4754234nzh; Mon, 24 Apr 2006 17:19:05 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 15sm779486nzn.2006.04.24.17.19.03; Mon, 24 Apr 2006 17:19:04 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k3P0IqH7001263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Apr 2006 09:18:52 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k3P0IppR001262; Tue, 25 Apr 2006 09:18:51 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 25 Apr 2006 09:18:51 +0900 From: Pyun YongHyeon To: Brad Message-ID: <20060425001851.GB946@cdnetworks.co.kr> References: <001201c666d4$b69dc290$0201a8c0@oxy> <20060423140833.V13011@maildrop.int.zabbadoz.net> <20060424234934.GA946@cdnetworks.co.kr> <20060425000106.GF14517@blar.home.comstyle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060425000106.GF14517@blar.home.comstyle.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: Marvell 88E8053 lan controller support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 00:19:12 -0000 On Mon, Apr 24, 2006 at 08:01:06PM -0400, Brad wrote: > On Tue, Apr 25, 2006 at 08:49:34AM +0900, Pyun YongHyeon wrote: > > On Mon, Apr 24, 2006 at 07:51:05AM -0700, othermark wrote: > > > Bjoern A. Zeeb wrote: > > > > > > > On Sun, 23 Apr 2006, OxY wrote: > > > > > > > >> hi! > > > >> > > > >> my question is when will this chip being supported by 6.x? > > > > > > > > for x>1 maybe. > > > > > > > >> or is it supported now and i didn't find the proper driver? :) > > > > > > > > search freebsd-net archive of Jan 2006, posting from andre oppermann > > > > and do not forget to read the follow-ups. > > > > > > Just so other people don't have to do the rummaging, here's the link from > > > gmane.org. > > > > > > http://thread.gmane.org/gmane.os.freebsd.current/79126/focus=79126 > > > > > > I too am hoping someone will step up to the plate and this support will be > > > integrated into -current. > > > > > > > I've tried their driver on CURRENT(It needs a minor modification to > > compile on CURRENT). But the driver didn't recognize link and even > > it panicked with numeros witness warnings when I enabled jumbo frame > > support. > > In addition it didn't attach for DGE530T. I think there driver is > > in experimental stage not for production use. In order to support > > Yukon II we need a documentation from Marvell. > > It is *extremely* unlikely that you will ever see documentation for the > Yukon II from Marvell. At this point the only option is to reverse > engineer the existing driver and/or use the new Linux driver as a source > of information. :-( Since they released source code for FreeBSD I can't see any point not releasing the documentation. However I'm happy as they didn't released binary only driver such as nve(4). Getting hardware information from Linux driver source would be more better option due to the complexity of Marvell's driver, I guess. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Tue Apr 25 00:35:52 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E879D16A403 for ; Tue, 25 Apr 2006 00:35:52 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from mail.comstyle.com (toronto-hs-216-138-195-228.s-ip.magma.ca [216.138.195.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B55843D5C for ; Tue, 25 Apr 2006 00:35:52 +0000 (GMT) (envelope-from brad@comstyle.com) Received: from blar.home.comstyle.com (blar.home.comstyle.com [IPv6:2001:240:589:1::3]) by fubar.home.comstyle.com (Postfix) with ESMTP id 2CD73A3A63 for ; Mon, 24 Apr 2006 20:35:51 -0400 (EDT) Received: by blar.home.comstyle.com (Postfix, from userid 1000) id 4FD36D3718; Mon, 24 Apr 2006 20:35:50 -0400 (EDT) Date: Mon, 24 Apr 2006 20:35:49 -0400 From: Brad To: freebsd-net@freebsd.org Message-ID: <20060425003549.GG14517@blar.home.comstyle.com> References: <001201c666d4$b69dc290$0201a8c0@oxy> <20060423140833.V13011@maildrop.int.zabbadoz.net> <20060424234934.GA946@cdnetworks.co.kr> <20060425000106.GF14517@blar.home.comstyle.com> <20060425001851.GB946@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060425001851.GB946@cdnetworks.co.kr> User-Agent: Mutt/1.4.2i Subject: Re: Marvell 88E8053 lan controller support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 00:35:53 -0000 On Tue, Apr 25, 2006 at 09:18:51AM +0900, Pyun YongHyeon wrote: > On Mon, Apr 24, 2006 at 08:01:06PM -0400, Brad wrote: > > On Tue, Apr 25, 2006 at 08:49:34AM +0900, Pyun YongHyeon wrote: > > > On Mon, Apr 24, 2006 at 07:51:05AM -0700, othermark wrote: > > > > Bjoern A. Zeeb wrote: > > > > > > > > > On Sun, 23 Apr 2006, OxY wrote: > > > > > > > > > >> hi! > > > > >> > > > > >> my question is when will this chip being supported by 6.x? > > > > > > > > > > for x>1 maybe. > > > > > > > > > >> or is it supported now and i didn't find the proper driver? :) > > > > > > > > > > search freebsd-net archive of Jan 2006, posting from andre oppermann > > > > > and do not forget to read the follow-ups. > > > > > > > > Just so other people don't have to do the rummaging, here's the link from > > > > gmane.org. > > > > > > > > http://thread.gmane.org/gmane.os.freebsd.current/79126/focus=79126 > > > > > > > > I too am hoping someone will step up to the plate and this support will be > > > > integrated into -current. > > > > > > > > > > I've tried their driver on CURRENT(It needs a minor modification to > > > compile on CURRENT). But the driver didn't recognize link and even > > > it panicked with numeros witness warnings when I enabled jumbo frame > > > support. > > > In addition it didn't attach for DGE530T. I think there driver is > > > in experimental stage not for production use. In order to support > > > Yukon II we need a documentation from Marvell. > > > > It is *extremely* unlikely that you will ever see documentation for the > > Yukon II from Marvell. At this point the only option is to reverse > > engineer the existing driver and/or use the new Linux driver as a source > > of information. > > :-( > > Since they released source code for FreeBSD I can't see any point > not releasing the documentation. Source exists for newer Broadcom Gig chips (575x and derivatives) yet there is no documentation available for that either. > However I'm happy as they didn't released binary only driver such as nve(4). True, though nve(4) never really worked. Work has been done to resolve the binary blob issue and have a working driver. FreeBSD needs to catch up. > Getting hardware information from Linux driver source would be more > better option due to the complexity of Marvell's driver, I guess. This is most likely the right approach. From owner-freebsd-net@FreeBSD.ORG Tue Apr 25 02:57:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15AA016A401 for ; Tue, 25 Apr 2006 02:57:16 +0000 (UTC) (envelope-from kbyanc@posi.net) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C3F343D48 for ; Tue, 25 Apr 2006 02:57:15 +0000 (GMT) (envelope-from kbyanc@posi.net) Received: from pimout7-ext.prodigy.net (pimout7-int.prodigy.net [207.115.4.147]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id k3P2v4bJ024947 for ; Mon, 24 Apr 2006 22:57:04 -0400 X-ORBL: [70.231.132.141] Received: from gateway.posi.net (adsl-70-231-132-141.dsl.snfc21.sbcglobal.net [70.231.132.141]) by pimout7-ext.prodigy.net (8.13.6 out.dk/8.13.6) with ESMTP id k3P2vCI3028264; Mon, 24 Apr 2006 22:57:13 -0400 Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (Postfix) with ESMTP id 48CB275E05F; Mon, 24 Apr 2006 21:05:16 -0700 (PDT) Date: Mon, 24 Apr 2006 21:05:15 -0700 (PDT) From: Kelly Yancey To: Amit Mondal In-Reply-To: Message-ID: <20060424210235.T44267@gateway.posi.net> References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-900672489-1145937915=:44267" Cc: freebsd-net@freebsd.org Subject: Re: freeBSD /ipfw/ divert socket X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 02:57:16 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-900672489-1145937915=:44267 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 21 Apr 2006, Amit Mondal wrote: > Hi All, > > I need a little help with FreeBSD Kernel stuff. I wanna use Divert Socket to > sniff IP packet in FreeBSD. > For that I have compiled the kernel with options IPDIVERT and everything is > ok. > > Now, when I am not really sniffing and re-injecting the packet back to the > network stack, it is basically dropping all the packets. But I want it > pass-through it, when no application is reading at divert socket. My > question is, HOW CAN I MAKE IT PASS-THROUGH? IF NO APPLICATION IS READING > FROM DIVERT SOCKET, IT SHOULD WORK AS IF THERE IS NO DIVERT SOCKET. > > Thanks in adavnce > > Rgds > Amit > Attached is a really old patch I made against FreeBSD 4.7. It might apply to 4.9. Even if it doesn't, it should give you a pretty good idea how to implement the functionality you desire. Kelly -- Kelly Yancey - kbyanc@{posi.net,FreeBSD.org} - kelly@nttmcl.com FreeBSD, The Power To Serve: http://www.freebsd.org/ --0-900672489-1145937915=:44267 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ipfw2-fwd.diff" Content-Transfer-Encoding: BASE64 Content-ID: <20060424210515.G44267@gateway.posi.net> Content-Description: Content-Disposition: attachment; filename="ipfw2-fwd.diff" SW5kZXg6IGlwX2Z3Mi5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1Mg ZmlsZTogL2hvbWUvY3ZzL2Fjcy9iYXNlL3NyYy9zeXMvbmV0aW5ldC9pcF9m dzIuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuOQ0KcmV0cmlldmluZyBy ZXZpc2lvbiAxLjExDQpkaWZmIC11IC1wIC1yMS45IC1yMS4xMQ0KLS0tIGlw X2Z3Mi5jCTMgSmFuIDIwMDMgMjM6MzQ6MTkgLTAwMDAJMS45DQorKysgaXBf ZncyLmMJOCBKYW4gMjAwMyAwNjoxNDo0OCAtMDAwMAkxLjExDQpAQCAtNTgw LDE3ICs1ODAsMTcgQEAgaXBmd19sb2coc3RydWN0IGlwX2Z3ICpmLCB1X2lu dCBobGVuLCBzdA0KIAl9DQogCWlmIChvaWYgfHwgbS0+bV9wa3RoZHIucmN2 aWYpDQogCQlsb2coTE9HX1NFQ1VSSVRZIHwgTE9HX0lORk8sDQotCQkgICAg ImlwZnc6ICVkICVzICVzICVzIHZpYSAlcyVkJXNcbiIsDQorCQkgICAgImlw Znc6ICVkICVzICVzICVzIHZpYSAlcyVkJXMgKGxheWVyICVkKVxuIiwNCiAJ CSAgICBmID8gZi0+cnVsZW51bSA6IC0xLA0KIAkJICAgIGFjdGlvbiwgcHJv dG8sIG9pZiA/ICJvdXQiIDogImluIiwNCiAJCSAgICBvaWYgPyBvaWYtPmlm X25hbWUgOiBtLT5tX3BrdGhkci5yY3ZpZi0+aWZfbmFtZSwNCiAJCSAgICBv aWYgPyBvaWYtPmlmX3VuaXQgOiBtLT5tX3BrdGhkci5yY3ZpZi0+aWZfdW5p dCwNCi0JCSAgICBmcmFnbWVudCk7DQorCQkgICAgZnJhZ21lbnQsIGVoID8g MiA6IDMpOw0KIAllbHNlDQogCQlsb2coTE9HX1NFQ1VSSVRZIHwgTE9HX0lO Rk8sDQotCQkgICAgImlwZnc6ICVkICVzICVzIFtubyBpZiBpbmZvXSVzXG4i LA0KKwkJICAgICJpcGZ3OiAlZCAlcyAlcyBbbm8gaWYgaW5mb10lcyAobGF5 ZXIgJWQpXG4iLA0KIAkJICAgIGYgPyBmLT5ydWxlbnVtIDogLTEsDQotCQkg ICAgYWN0aW9uLCBwcm90bywgZnJhZ21lbnQpOw0KKwkJICAgIGFjdGlvbiwg cHJvdG8sIGZyYWdtZW50LCBlaCA/IDIgOiAzKTsNCiAJaWYgKGxpbWl0X3Jl YWNoZWQpDQogCQlsb2coTE9HX1NFQ1VSSVRZIHwgTE9HX05PVElDRSwNCiAJ CSAgICAiaXBmdzogbGltaXQgJWQgcmVhY2hlZCBvbiBlbnRyeSAlZFxuIiwN CkBAIC0xOTM5LDggKzE5MzksMTAgQEAgY2hlY2tfYm9keToNCiAJCQkJZ290 byBkb25lOw0KIA0KIAkJCWNhc2UgT19GT1JXQVJEX0lQOg0KLQkJCQlpZiAo YXJncy0+ZWgpCS8qIG5vdCB2YWxpZCBvbiBsYXllcjIgcGt0cyAqLw0KLQkJ CQkJYnJlYWs7DQorCQkJCWlmIChhcmdzLT5laCAmJiBvaWYgIT0gTlVMTCkg ew0KKwkJCQkJLyogaWdub3JlIG91dGJvdW5kIGxheWVyMiBwa3RzICovDQor CQkJCQlnb3RvIG5leHRfcnVsZTsNCisJCQkJfQ0KIAkJCQlpZiAoIXEgfHwg ZHluX2RpciA9PSBNQVRDSF9GT1JXQVJEKQ0KIAkJCQkJYXJncy0+bmV4dF9o b3AgPQ0KIAkJCQkJICAgICYoKGlwZndfaW5zbl9zYSAqKWNtZCktPnNhOw0K SW5kZXg6IGlwX2lucHV0LmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJD UyBmaWxlOiAvaG9tZS9jdnMvYWNzL2Jhc2Uvc3JjL3N5cy9uZXRpbmV0L2lw X2lucHV0LmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjE0DQpyZXRyaWV2 aW5nIHJldmlzaW9uIDEuMTYNCmRpZmYgLXUgLXAgLXIxLjE0IC1yMS4xNg0K LS0tIGlwX2lucHV0LmMJMyBKYW4gMjAwMyAwNDo0Njo1MyAtMDAwMAkxLjE0 DQorKysgaXBfaW5wdXQuYwk4IEphbiAyMDAzIDA2OjE2OjA2IC0wMDAwCTEu MTYNCkBAIC0zNjksOCArMzY5LDE4IEBAIGlwX2lucHV0KHN0cnVjdCBtYnVm ICptKQ0KIAkJY2FzZSBQQUNLRVRfVEFHX0lQRk9SV0FSRDoNCiAJCQlhcmdz Lm5leHRfaG9wID0gKHN0cnVjdCBzb2NrYWRkcl9pbiAqKW0tPm1faGRyLm1o X2RhdGE7DQogCQkJYnJlYWs7DQorCQljYXNlIFBBQ0tFVF9UQUdfSVBGT1JX QVJEIHwgTV9QUk9UTzU6IHsNCisJCQkvKiBYWFggVGhpcyBzaG91bGQgYmUg dGFrZW4gb3V0IGFuZCBzaG90ISAqLw0KKwkJCXN0cnVjdCBtYnVmICp0YWcg PSBtOw0KKwkJCW0gPSBtLT5tX25leHQ7DQorCQkJYXJncy5uZXh0X2hvcCA9 IChzdHJ1Y3Qgc29ja2FkZHJfaW4gKil0YWctPm1faGRyLm1oX2RhdGE7DQor CQkJbV9mcmVlKHRhZyk7DQorCQkJS0FTU0VSVChtLT5tX3R5cGUgIT0gTVRf VEFHLCAoIlhYWCBraWxsIG1lIikpOw0KKwkJCWdvdG8gcG9zdHRhZ3M7DQor CQkJfQ0KIAkJfQ0KIAl9DQorcG9zdHRhZ3M6DQogDQogCUtBU1NFUlQobSAh PSBOVUxMICYmIChtLT5tX2ZsYWdzICYgTV9QS1RIRFIpICE9IDAsDQogCSAg ICAoImlwX2lucHV0OiBubyBIRFIiKSk7DQpJbmRleDogaWZfZXRoZXJzdWJy LmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9j dnMvYWNzL2Jhc2Uvc3JjL3N5cy9uZXQvaWZfZXRoZXJzdWJyLmMsdg0KcmV0 cmlldmluZyByZXZpc2lvbiAxLjkNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4x MQ0KZGlmZiAtdSAtcCAtcjEuOSAtcjEuMTENCi0tLSBpZl9ldGhlcnN1YnIu YwkzIEphbiAyMDAzIDA0OjQwOjA2IC0wMDAwCTEuOQ0KKysrIGlmX2V0aGVy c3Vici5jCTggSmFuIDIwMDMgMDY6MTY6MDUgLTAwMDAJMS4xMQ0KQEAgLTUw MSw3ICs1MDEsNyBAQCBldGhlcl9pcGZ3X2NoayhzdHJ1Y3QgbWJ1ZiAqKm0w LCBzdHJ1Y3QgDQogCWFyZ3Mub2lmID0gZmxhZ3MgJiBFVEhFUl9JUEZXX09V VFBVVCA/IGlmcCA6IE5VTEw7DQogCWFyZ3MuZGl2ZXJ0X3J1bGUgPSBkaXZl cnRfcnVsZTsNCiAJYXJncy5ydWxlID0gKnJ1bGU7CS8qIG1hdGNoaW5nIHJ1 bGUgdG8gcmVzdGFydAkJKi8NCi0JYXJncy5uZXh0X2hvcCA9IE5VTEw7CS8q IHdlIGRvIG5vdCBzdXBwb3J0IGZvcndhcmQgeWV0CSovDQorCWFyZ3MubmV4 dF9ob3AgPSBOVUxMOwkvKiBJUEZPUldBUkQJCQkJKi8NCiAJYXJncy5laCA9 ICZzYXZlX2VoOwkvKiBNQUMgaGVhZGVyIGZvciBicmlkZ2VkL01BQyBwYWNr ZXRzCSovDQogCWkgPSBpcF9md19jaGtfcHRyKCZhcmdzKTsNCiAJKm0wID0g YXJncy5tOw0KQEAgLTUxMCw3ICs1MTAsNyBAQCBldGhlcl9pcGZ3X2Noayhz dHJ1Y3QgbWJ1ZiAqKm0wLCBzdHJ1Y3QgDQogCWlmICggKGkgJiBJUF9GV19Q T1JUX0RFTllfRkxBRykgfHwgKm0wID09IE5VTEwpIC8qIGRyb3AgKi8NCiAJ CXJldHVybiAwOw0KIA0KLQlpZiAoaSA9PSAwKSAvKiBhIFBBU1MgcnVsZS4g ICovDQorCWlmIChpID09IDAgJiYgYXJncy5uZXh0X2hvcCA9PSBOVUxMKSAv KiBhIFBBU1MgcnVsZS4gICovDQogCQlyZXR1cm4gMTsNCiANCiAJaWYgKERV TU1ZTkVUX0xPQURFRCAmJiAoaSAmIElQX0ZXX1BPUlRfRFlOVF9GTEFHKSkg ew0KQEAgLTU4OSw2ICs1ODksMzYgQEAgZXRoZXJfaXBmd19jaGsoc3RydWN0 IG1idWYgKiptMCwgc3RydWN0IA0KIA0KIAkJLyogSWYgJ3RlZScsIGNvbnRp bnVlIHdpdGggb3JpZ2luYWwgcGFja2V0ICovDQogCQlyZXR1cm4gKGNsb25l ICE9IE5VTEwpOw0KKwl9DQorI2VuZGlmDQorDQorI2lmZGVmIElORVQNCisJ LyoNCisJICogSVBGSVJFV0FMTF9GT1JXQVJEDQorCSAqDQorCSAqIFhYWCBP bmx5IHN1cHBvcnQgSVAgZm9yd2FyZGluZyBkdXJpbmcgaW4tYm91bmQgcHJv Y2Vzc2luZy4NCisJICovDQorCWlmIChpID09IDAgJiYgYXJncy5uZXh0X2hv cCAhPSBOVUxMICYmIGFyZ3Mub2lmID09IE5VTEwpIHsNCisJCS8qDQorCQkg KiBQYWNrZXQgbXVzdCBiZSBJUCB0byBtYXRjaCBhbiBJUCBmb3J3YXJkIHJ1 bGUuICBUYWcgaXQgYW5kDQorCQkgKiBwYXNzIGl0IGFsb25nIHRvIGlwX2lu cHV0KCkgZm9yIHByb2Nlc3NpbmcuDQorCQkgKiBYWFggUmVsaWVzIG9uIG5v dGhpbmcgaW4gdGhlIG5ldGlzciBwcm9jZXNzaW5nIGV4YW1pbmluZw0KKwkJ ICogICAgIHRoZSBsZWFkaW5nIG1idWYgYXMgaXQncyBvdXIgdGFnIHJhdGhl ciB0aGFuIGEgcHJvcGVyDQorCQkgKiAgICAgcGFja2V0IGhlYWRlci4NCisJ CSAqIFhYWCBUaGlzIGlzIHByZXR0eSBleHBlbnNpdmUgKGFuZCB1Z2x5ISku ICBUaGlzIGNhbiBiZQ0KKwkJICogICAgIGNsZWFuZWQgdXAgdXNpbmcgLWN1 cnJlbnQncyBwYWNrZXQgdGFnZ2luZy4NCisJCSAqLw0KKwkJc3RydWN0IG1i dWYgKnRhZzsNCisNCisJCU1HRVRIRFIodGFnLCBNX0RPTlRXQUlULCBNVF9U QUcpOw0KKwkJdGFnLT5tX2hkci5taF9mbGFncyA9IFBBQ0tFVF9UQUdfSVBG T1JXQVJEIHwgTV9QUk9UTzU7IC8qIEhhY2shICovDQorCQl0YWctPm1faGRy Lm1oX2RhdGEgPSAoY2FkZHJfdClhcmdzLm5leHRfaG9wOw0KKwkJdGFnLT5t X2hkci5taF9uZXh0ID0gKm0wOw0KKw0KKwkJc2NoZWRuZXRpc3IoTkVUSVNS X0lQKTsNCisJCSh2b2lkKSBJRl9IQU5ET0ZGKCZpcGludHJxLCB0YWcsIE5V TEwpOw0KKwkJKm0wID0gTlVMTDsNCisJCXJldHVybiAwOw0KIAl9DQogI2Vu ZGlmDQogDQo= --0-900672489-1145937915=:44267-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 25 03:12:35 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AF8116A401 for ; Tue, 25 Apr 2006 03:12:35 +0000 (UTC) (envelope-from kbyanc@posi.net) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 296E543D48 for ; Tue, 25 Apr 2006 03:12:34 +0000 (GMT) (envelope-from kbyanc@posi.net) Received: from pimout7-ext.prodigy.net (pimout7-int.prodigy.net [207.115.4.147]) by ylpvm15.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id k3P3CjYA004125 for ; Mon, 24 Apr 2006 23:12:45 -0400 X-ORBL: [70.231.132.141] Received: from gateway.posi.net (adsl-70-231-132-141.dsl.snfc21.sbcglobal.net [70.231.132.141]) by pimout7-ext.prodigy.net (8.13.6 out.dk/8.13.6) with ESMTP id k3P3CVbU077784; Mon, 24 Apr 2006 23:12:31 -0400 Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (Postfix) with ESMTP id E74D475E05F; Mon, 24 Apr 2006 21:20:34 -0700 (PDT) Date: Mon, 24 Apr 2006 21:20:34 -0700 (PDT) From: Kelly Yancey To: Amit Mondal In-Reply-To: <20060424210235.T44267@gateway.posi.net> Message-ID: <20060424212004.B44267@gateway.posi.net> References: <20060424210235.T44267@gateway.posi.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-256389840-1145938834=:44267" Cc: freebsd-net@freebsd.org Subject: Re: freeBSD /ipfw/ divert socket X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 03:12:35 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-256389840-1145938834=:44267 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 24 Apr 2006, Kelly Yancey wrote: > On Fri, 21 Apr 2006, Amit Mondal wrote: > > > Hi All, > > > > I need a little help with FreeBSD Kernel stuff. I wanna use Divert Socket to > > sniff IP packet in FreeBSD. > > For that I have compiled the kernel with options IPDIVERT and everything is > > ok. > > > > Now, when I am not really sniffing and re-injecting the packet back to the > > network stack, it is basically dropping all the packets. But I want it > > pass-through it, when no application is reading at divert socket. My > > question is, HOW CAN I MAKE IT PASS-THROUGH? IF NO APPLICATION IS READING > > FROM DIVERT SOCKET, IT SHOULD WORK AS IF THERE IS NO DIVERT SOCKET. > > > > Thanks in adavnce > > > > Rgds > > Amit > > > > Attached is a really old patch I made against FreeBSD 4.7. It might > apply to 4.9. Even if it doesn't, it should give you a pretty good idea > how to implement the functionality you desire. > > Kelly > Sorry, wrong patch. The correct patch is attached. Kelly -- Kelly Yancey - kbyanc@{posi.net,FreeBSD.org} - kelly@nttmcl.com FreeBSD, The Power To Serve: http://www.freebsd.org/ --0-256389840-1145938834=:44267 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="divert-nop.diff" Content-Transfer-Encoding: BASE64 Content-ID: <20060424212034.I44267@gateway.posi.net> Content-Description: Content-Disposition: attachment; filename="divert-nop.diff" SW5kZXg6IHN5cy9uZXRpbmV0L2lwX2RpdmVydC5jDQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvY3ZzL2Fjcy9iYXNlL3NyYy9z eXMvbmV0aW5ldC9pcF9kaXZlcnQuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9u IDEuMw0KcmV0cmlldmluZyByZXZpc2lvbiAxLjQNCmRpZmYgLXUgLXAgLXIx LjMgLXIxLjQNCi0tLSBpcF9kaXZlcnQuYwkxMCBPY3QgMjAwMiAyMDo0Mjow MCAtMDAwMAkxLjMNCisrKyBpcF9kaXZlcnQuYwkyMyBOb3YgMjAwMiAwNToz NDoxMCAtMDAwMAkxLjQNCkBAIC0xMDksNiArMTA5LDIzIEBAIHN0YXRpYyB1 X2xvbmcJZGl2X3JlY3ZzcGFjZSA9IERJVlJDVlE7CS8NCiAvKiBPcHRpbWl6 YXRpb246IGhhdmUgdGhpcyBwcmVpbml0aWFsaXplZCAqLw0KIHN0YXRpYyBz dHJ1Y3Qgc29ja2FkZHJfaW4gZGl2c3JjID0geyBzaXplb2YoZGl2c3JjKSwg QUZfSU5FVCB9Ow0KIA0KKw0KK3N0YXRpYyBpbnQJZGl2X291dHB1dChzdHJ1 Y3Qgc29ja2V0ICpzbywgc3RydWN0IG1idWYgKm0sDQorCQkJICAgc3RydWN0 IHNvY2thZGRyX2luICpzaW4sIHN0cnVjdCBtYnVmICpjb250cm9sKTsNCitz dGF0aWMgaW50CWRpdl9hdHRhY2goc3RydWN0IHNvY2tldCAqc28sIGludCBw cm90bywgc3RydWN0IHByb2MgKnApOw0KK3N0YXRpYyBpbnQJZGl2X2RldGFj aChzdHJ1Y3Qgc29ja2V0ICpzbyk7DQorc3RhdGljIGludAlkaXZfYWJvcnQo c3RydWN0IHNvY2tldCAqc28pOw0KK3N0YXRpYyBpbnQJZGl2X2Rpc2Nvbm5l Y3Qoc3RydWN0IHNvY2tldCAqc28pOw0KK3N0YXRpYyBpbnQJZGl2X2JpbmQo c3RydWN0IHNvY2tldCAqc28sIHN0cnVjdCBzb2NrYWRkciAqbmFtLA0KKwkJ CSBzdHJ1Y3QgcHJvYyAqcCk7DQorc3RhdGljIGludAlkaXZfc2h1dGRvd24o c3RydWN0IHNvY2tldCAqc28pOw0KK3N0YXRpYyBpbnQJZGl2X3NlbmQoc3Ry dWN0IHNvY2tldCAqc28sIGludCBmbGFncywgc3RydWN0IG1idWYgKm0sDQor CQkJIHN0cnVjdCBzb2NrYWRkciAqbmFtLCBzdHJ1Y3QgbWJ1ZiAqY29udHJv bCwNCisJCQkgc3RydWN0IHByb2MgKnApOw0KK3N0YXRpYyBpbnQJZGl2X3Bj Ymxpc3QoU1lTQ1RMX0hBTkRMRVJfQVJHUyk7DQorDQorDQorDQogLyoNCiAg KiBJbml0aWFsaXplIGRpdmVydCBjb25uZWN0aW9uIGJsb2NrIHF1ZXVlLg0K ICAqLw0KQEAgLTE0Niw4ICsxNjMsOSBAQCBkaXZfaW5wdXQoc3RydWN0IG1i dWYgKm0sIGludCBvZmYsIGludCBwDQogICogdGhlbiBwYXNzIHRoZW0gYWxv bmcgd2l0aCBtYnVmIGNoYWluLg0KICAqLw0KIHZvaWQNCi1kaXZlcnRfcGFj a2V0KHN0cnVjdCBtYnVmICptLCBpbnQgaW5jb21pbmcsIGludCBwb3J0LCBp bnQgcnVsZSkNCitkaXZlcnRfcGFja2V0KHN0cnVjdCBtYnVmICptLCBpbnQg ZmxhZ3MsIGludCBwb3J0LCBpbnQgcnVsZSkNCiB7DQorCXN0YXRpYyBzdHJ1 Y3Qgc29ja2V0ICpkaXZudWxsc287DQogCXN0cnVjdCBpcCAqaXA7DQogCXN0 cnVjdCBpbnBjYiAqaW5wOw0KIAlzdHJ1Y3Qgc29ja2V0ICpzYTsNCkBAIC0x NjksNyArMTg3LDcgQEAgZGl2ZXJ0X3BhY2tldChzdHJ1Y3QgbWJ1ZiAqbSwg aW50IGluY29taQ0KIAkgKiBCdXQgb25seSBmb3IgaW5jb21pbmcgcGFja2V0 cy4NCiAJICovDQogCWRpdnNyYy5zaW5fYWRkci5zX2FkZHIgPSAwOw0KLQlp ZiAoaW5jb21pbmcpIHsNCisJaWYgKGZsYWdzICYgSVBfRElWRVJUX0lOQ09N SU5HKSB7DQogCQlzdHJ1Y3QgaWZhZGRyICppZmE7DQogDQogCQkvKiBTYW5p dHkgY2hlY2sgKi8NCkBAIC0yMjcsNiArMjQ1LDIyIEBAIGRpdmVydF9wYWNr ZXQoc3RydWN0IG1idWYgKm0sIGludCBpbmNvbWkNCiAJCQltX2ZyZWVtKG0p Ow0KIAkJZWxzZQ0KIAkJCXNvcndha2V1cChzYSk7DQorCX0gZWxzZSBpZiAo ZmxhZ3MgJiBJUF9ESVZFUlRfRE9OVERST1ApIHsNCisJCS8qIFByZXRlbmQg dGhlIHBhY2tldCB3YXMgcGFzc2VkIGJhY2sgdW5jaGFuZ2VkLiAqLw0KKwkJ aXBzdGF0Lmlwc19kZWxpdmVyZWQtLTsNCisJCWlmIChkaXZudWxsc28gPT0g TlVMTCkgew0KKwkJCS8qDQorCQkJICogQWxsb2NhdGUgYSBkdW1teSBzb2Nr ZXQgZm9yIGlwX291dHB1dCgpIHdoZW4NCisJCQkgKiBsb29waW5nIGJhY2sg ZGl2ZXJ0ZWQgcGFja2V0cy4NCisJCQkgKi8NCisJCQlpZiAoc29jcmVhdGUo UEZfSU5FVCwgJmRpdm51bGxzbywgU09DS19SQVcsDQorCQkJICAgIElQUFJP VE9fRElWRVJULCAmcHJvYzApICE9IDApIHsNCisJCQkJbV9mcmVlbShtKTsN CisJCQkJaXBzdGF0Lmlwc19vZHJvcHBlZCsrOw0KKwkJCQlyZXR1cm47DQor CQkJfQ0KKwkJfQ0KKwkJZGl2X291dHB1dChkaXZudWxsc28sIG0sICZkaXZz cmMsIE5VTEwpOw0KIAl9IGVsc2Ugew0KIAkJbV9mcmVlbShtKTsNCiAJCWlw c3RhdC5pcHNfbm9wcm90bysrOw0KQEAgLTI0NSw4ICsyNzksOCBAQCBzdGF0 aWMgaW50DQogZGl2X291dHB1dChzdHJ1Y3Qgc29ja2V0ICpzbywgc3RydWN0 IG1idWYgKm0sDQogCXN0cnVjdCBzb2NrYWRkcl9pbiAqc2luLCBzdHJ1Y3Qg bWJ1ZiAqY29udHJvbCkNCiB7DQotCWludCBlcnJvciA9IDA7DQogCXN0cnVj dCBtX2hkciBkaXZlcnRfdGFnOw0KKwlpbnQgZXJyb3IgPSAwOw0KIA0KIAkv Kg0KIAkgKiBQcmVwYXJlIHRoZSB0YWcgZm9yIGRpdmVydCBpbmZvLiBOb3Rl IHRoYXQgYSBwYWNrZXQNCkluZGV4OiBzeXMvbmV0aW5ldC9pcF9mdy5oDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvY3ZzL2Fj cy9iYXNlL3NyYy9zeXMvbmV0aW5ldC9pcF9mdy5oLHYNCnJldHJpZXZpbmcg cmV2aXNpb24gMS40DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNQ0KZGlmZiAt dSAtcCAtcjEuNCAtcjEuNQ0KLS0tIGlwX2Z3LmgJMTUgTm92IDIwMDIgMDA6 MTE6NDIgLTAwMDAJMS40DQorKysgaXBfZncuaAkyMyBOb3YgMjAwMiAwNToz NDoxMCAtMDAwMAkxLjUNCkBAIC0zMzAsNiArMzMwLDcgQEAgc3RydWN0IGlw ZndfZHluX3J1bGUgew0KICAqLw0KICNpZmRlZiBfS0VSTkVMDQogDQorI2Rl ZmluZQlJUF9GV19QT1JUX01BU0sJCTB4MGZmZmYNCiAjZGVmaW5lCUlQX0ZX X1BPUlRfRFlOVF9GTEFHCTB4MTAwMDANCiAjZGVmaW5lCUlQX0ZXX1BPUlRf VEVFX0ZMQUcJMHgyMDAwMA0KICNkZWZpbmUJSVBfRldfUE9SVF9ERU5ZX0ZM QUcJMHg0MDAwMA0KSW5kZXg6IHN5cy9uZXRpbmV0L2lwX2Z3Mi5jDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvY3ZzL2Fjcy9i YXNlL3NyYy9zeXMvbmV0aW5ldC9pcF9mdzIuYyx2DQpyZXRyaWV2aW5nIHJl dmlzaW9uIDEuNA0KcmV0cmlldmluZyByZXZpc2lvbiAxLjUNCmRpZmYgLXUg LXAgLXIxLjQgLXIxLjUNCi0tLSBpcF9mdzIuYwkxOSBOb3YgMjAwMiAyMDoy OTowMCAtMDAwMAkxLjQNCisrKyBpcF9mdzIuYwkyMyBOb3YgMjAwMiAwNToz NDoxMCAtMDAwMAkxLjUNCkBAIC00NjIsNiArNDYyLDEwIEBAIGlwZndfbG9n KHN0cnVjdCBpcF9mdyAqZiwgdV9pbnQgaGxlbiwgc3QNCiAJCWNhc2UgT19D T1VOVDoNCiAJCQlhY3Rpb24gPSAiQ291bnQiOw0KIAkJCWJyZWFrOw0KKwkJ Y2FzZSBPX0RJVkVSVF9OT1A6DQorCQkJc25wcmludGYoU05QQVJHUyhhY3Rp b24yLCAwKSwgIkRpdmVydC9Ob3AgJWQiLA0KKwkJCQljbWQtPmFyZzEpOw0K KwkJCWJyZWFrOw0KIAkJY2FzZSBPX0RJVkVSVDoNCiAJCQlzbnByaW50ZihT TlBBUkdTKGFjdGlvbjIsIDApLCAiRGl2ZXJ0ICVkIiwNCiAJCQkJY21kLT5h cmcxKTsNCkBAIC0xMjE1LDYgKzEyMTksMTAgQEAgbG9va3VwX25leHRfcnVs ZShzdHJ1Y3QgaXBfZncgKm1lKQ0KICAqDQogICoJCS0gSWYgSVBfRldfUE9S VF9EWU5UX0ZMQUcgaXMgc2V0LCBpbnRlcnByZXQgdGhlIGxvd2VyDQogICoJ CSAgMTYgYml0cyBhcyBhIGR1bW15bmV0IHBpcGUgbnVtYmVyIGluc3RlYWQg b2YgZGl2ZXJ0aW5nDQorICoNCisgKgkJLSBJZiBJUF9GV19QT1JUX05PRFJP UF9GTEFHIGlzIHNldCwgZG9uJ3QgZHJvcCB0aGUgcGFja2V0DQorICoJCSAg aWYgdGhlcmUgaXMgbm8gbGlzdGVuZXIgb24gdGhlIGRpdmVydCBwb3J0OyBp bnN0ZWFkIHJlaW5qZWN0DQorICoJCSAgdGhlIHBhY2tldCBpbW1lZGlhdGVs eS4NCiAgKi8NCiANCiBzdGF0aWMgaW50DQpAQCAtMTg2MiwxNCArMTg3MCwx NyBAQCBjaGVja19ib2R5Og0KIAkJCQlyZXR2YWwgPSBjbWQtPmFyZzEgfCBJ UF9GV19QT1JUX0RZTlRfRkxBRzsNCiAJCQkJZ290byBkb25lOw0KIA0KKwkJ CWNhc2UgT19ESVZFUlRfTk9QOg0KIAkJCWNhc2UgT19ESVZFUlQ6DQogCQkJ Y2FzZSBPX1RFRToNCiAJCQkJaWYgKGFyZ3MtPmVoKSAvKiBub3Qgb24gbGF5 ZXIgMiAqLw0KIAkJCQkJYnJlYWs7DQogCQkJCWFyZ3MtPmRpdmVydF9ydWxl ID0gZi0+cnVsZW51bTsNCi0JCQkJcmV0dmFsID0gKGNtZC0+b3Bjb2RlID09 IE9fRElWRVJUKSA/DQotCQkJCSAgICBjbWQtPmFyZzEgOg0KLQkJCQkgICAg Y21kLT5hcmcxIHwgSVBfRldfUE9SVF9URUVfRkxBRzsNCisJCQkJcmV0dmFs ID0gY21kLT5hcmcxOw0KKwkJCQlpZiAoY21kLT5vcGNvZGUgPT0gT19ESVZF UlRfTk9QKQ0KKwkJCQkJcmV0dmFsIHw9IElQX0ZXX1BPUlRfTk9EUk9QX0ZM QUc7DQorCQkJCWVsc2UgaWYgKGNtZC0+b3Bjb2RlID09IE9fVEVFKQ0KKwkJ CQkJcmV0dmFsIHw9IElQX0ZXX1BPUlRfVEVFX0ZMQUc7DQogCQkJCWdvdG8g ZG9uZTsNCiANCiAJCQljYXNlIE9fQ09VTlQ6DQpAQCAtMjQzMSw2ICsyNDQy LDcgQEAgY2hlY2tfaXBmd19zdHJ1Y3Qoc3RydWN0IGlwX2Z3ICpydWxlLCBp bg0KIAkJY2FzZSBPX0RFTlk6DQogCQljYXNlIE9fUkVKRUNUOg0KIAkJY2Fz ZSBPX1NLSVBUTzoNCisJCWNhc2UgT19ESVZFUlRfTk9QOg0KIAkJY2FzZSBP X0RJVkVSVDoNCiAJCWNhc2UgT19URUU6DQogCQkJaWYgKGNtZGxlbiAhPSBG X0lOU05fU0laRShpcGZ3X2luc24pKQ0KSW5kZXg6IHN5cy9uZXRpbmV0L2lw X2Z3Mi5oDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hv bWUvY3ZzL2Fjcy9iYXNlL3NyYy9zeXMvbmV0aW5ldC9pcF9mdzIuaCx2DQpy ZXRyaWV2aW5nIHJldmlzaW9uIDEuMg0KcmV0cmlldmluZyByZXZpc2lvbiAx LjMNCmRpZmYgLXUgLXAgLXIxLjIgLXIxLjMNCi0tLSBpcF9mdzIuaAkxNSBO b3YgMjAwMiAwMDoxMTo0MyAtMDAwMAkxLjINCisrKyBpcF9mdzIuaAkyMyBO b3YgMjAwMiAwNTozNDoxMCAtMDAwMAkxLjMNCkBAIC0xMTAsNiArMTEwLDcg QEAgZW51bSBpcGZ3X29wY29kZXMgewkJLyogYXJndW1lbnRzICg0IGJ5dA0K IAlPX1NLSVBUTywJCS8qIGFyZzE9bmV4dCBydWxlIG51bWJlcgkqLw0KIAlP X1BJUEUsCQkJLyogYXJnMT1waXBlIG51bWJlcgkJKi8NCiAJT19RVUVVRSwJ CS8qIGFyZzE9cXVldWUgbnVtYmVyCQkqLw0KKwlPX0RJVkVSVF9OT1AsCQkv KiBhcmcxPXBvcnQgbnVtYmVyCQkqLw0KIAlPX0RJVkVSVCwJCS8qIGFyZzE9 cG9ydCBudW1iZXIJCSovDQogCU9fVEVFLAkJCS8qIGFyZzE9cG9ydCBudW1i ZXIJCSovDQogCU9fRk9SV0FSRF9JUCwJCS8qIGZ3ZCBzb2NrYWRkcgkJCSov DQpAQCAtMzU5LDkgKzM2MCwxMSBAQCBzdHJ1Y3QgX2lwZndfZHluX3J1bGUg ew0KICAqLw0KICNpZmRlZiBfS0VSTkVMDQogDQorI2RlZmluZSBJUF9GV19Q T1JUX01BU0sJCTB4MGZmZmYNCiAjZGVmaW5lCUlQX0ZXX1BPUlRfRFlOVF9G TEFHCTB4MTAwMDANCiAjZGVmaW5lCUlQX0ZXX1BPUlRfVEVFX0ZMQUcJMHgy MDAwMA0KICNkZWZpbmUJSVBfRldfUE9SVF9ERU5ZX0ZMQUcJMHg0MDAwMA0K KyNkZWZpbmUJSVBfRldfUE9SVF9OT0RST1BfRkxBRwkweDgwMDAwDQogDQog LyoNCiAgKiBhcmd1bWVudHMgZm9yIGNhbGxpbmcgaXBmd19jaGsoKSBhbmQg ZHVtbXluZXRfaW8oKS4gV2UgcHV0IHRoZW0NCkluZGV4OiBzeXMvbmV0aW5l dC9pcF9pbnB1dC5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmls ZTogL2hvbWUvY3ZzL2Fjcy9iYXNlL3NyYy9zeXMvbmV0aW5ldC9pcF9pbnB1 dC5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMA0KcmV0cmlldmluZyBy ZXZpc2lvbiAxLjExDQpkaWZmIC11IC1wIC1yMS4xMCAtcjEuMTENCi0tLSBp cF9pbnB1dC5jCTE5IE5vdiAyMDAyIDIwOjIzOjM0IC0wMDAwCTEuMTANCisr KyBpcF9pbnB1dC5jCTIzIE5vdiAyMDAyIDA1OjQyOjAzIC0wMDAwCTEuMTEN CkBAIC00NjMsNyArNDk2LDcgQEAgaXBoYWNrOg0KIAkJCWdvdG8gcGFzczsN CiAgICAgICAgICAgICAgICAgaWYgKERVTU1ZTkVUX0xPQURFRCAmJiAoaSAm IElQX0ZXX1BPUlRfRFlOVF9GTEFHKSAhPSAwKSB7DQogCQkJLyogU2VuZCBw YWNrZXQgdG8gdGhlIGFwcHJvcHJpYXRlIHBpcGUgKi8NCi0JCQlpcF9kbl9p b19wdHIobSwgaSYweGZmZmYsIEROX1RPX0lQX0lOLCAmYXJncyk7DQorCQkJ aXBfZG5faW9fcHRyKG0sIGkgJiBJUF9GV19QT1JUX01BU0ssIEROX1RPX0lQ X0lOLCZhcmdzKTsNCiAJCQlyZXR1cm47DQogCQl9DQogI2lmZGVmIElQRElW RVJUDQpAQCAtNzcyLDYgKzc5OCw3IEBAIGZvdW5kOg0KIAkgKi8NCiAJaWYg KGRpdmVydF9pbmZvICE9IDApIHsNCiAJCXN0cnVjdCBtYnVmICpjbG9uZSA9 IE5VTEw7DQorCQlpbnQgZmxhZ3MgPSBJUF9ESVZFUlRfSU5DT01JTkc7DQog DQogCQkvKiBDbG9uZSBwYWNrZXQgaWYgd2UncmUgZG9pbmcgYSAndGVlJyAq Lw0KIAkJaWYgKChkaXZlcnRfaW5mbyAmIElQX0ZXX1BPUlRfVEVFX0ZMQUcp ICE9IDApDQpAQCAtNzgzLDcgKzgxMCwxMCBAQCBmb3VuZDoNCiAJCWlwLT5p cF9vZmYgPSBodG9ucyhpcC0+aXBfb2ZmKTsNCiANCiAJCS8qIERlbGl2ZXIg cGFja2V0IHRvIGRpdmVydCBpbnB1dCByb3V0aW5lICovDQotCQlkaXZlcnRf cGFja2V0KG0sIDEsIGRpdmVydF9pbmZvICYgMHhmZmZmLCBhcmdzLmRpdmVy dF9ydWxlKTsNCisJCWlmICgoZGl2ZXJ0X2luZm8gJiBJUF9GV19QT1JUX05P RFJPUF9GTEFHKSAhPSAwKQ0KKwkJCWZsYWdzIHw9IElQX0RJVkVSVF9ET05U RFJPUDsNCisJCWRpdmVydF9wYWNrZXQobSwgZmxhZ3MsIGRpdmVydF9pbmZv ICYgSVBfRldfUE9SVF9NQVNLLA0KKwkJICAgIGFyZ3MuZGl2ZXJ0X3J1bGUp Ow0KIAkJaXBzdGF0Lmlwc19kZWxpdmVyZWQrKzsNCiANCiAJCS8qIElmICd0 ZWUnLCBjb250aW51ZSB3aXRoIG9yaWdpbmFsIHBhY2tldCAqLw0KSW5kZXg6 IHN5cy9uZXRpbmV0L2lwX291dHB1dC5jDQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQpSQ1MgZmlsZTogL2hvbWUvY3ZzL2Fjcy9iYXNlL3NyYy9zeXMvbmV0 aW5ldC9pcF9vdXRwdXQuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNw0K cmV0cmlldmluZyByZXZpc2lvbiAxLjgNCmRpZmYgLXUgLXAgLXIxLjcgLXIx LjgNCi0tLSBpcF9vdXRwdXQuYwkxOSBOb3YgMjAwMiAyMDozNzozOSAtMDAw MAkxLjcNCisrKyBpcF9vdXRwdXQuYwkyMyBOb3YgMjAwMiAwNTozNDoxMSAt MDAwMAkxLjgNCkBAIC02MjUsMTMgKzYyNSwxNCBAQCBza2lwX2lwc2VjOg0K IAkJCWFyZ3MuZHN0ID0gZHN0Ow0KIAkJCWFyZ3MuZmxhZ3MgPSBmbGFnczsN CiANCi0JCQllcnJvciA9IGlwX2RuX2lvX3B0cihtLCBvZmYgJiAweGZmZmYs IEROX1RPX0lQX09VVCwNCi0JCQkJJmFyZ3MpOw0KKwkJCWVycm9yID0gaXBf ZG5faW9fcHRyKG0sIG9mZiAmIElQX0ZXX1BPUlRfTUFTSywNCisJCQkgICAg RE5fVE9fSVBfT1VULCAmYXJncyk7DQogCQkJZ290byBkb25lOw0KIAkJfQ0K ICNpZmRlZiBJUERJVkVSVA0KIAkJaWYgKG9mZiAhPSAwICYmIChvZmYgJiBJ UF9GV19QT1JUX0RZTlRfRkxBRykgPT0gMCkgew0KIAkJCXN0cnVjdCBtYnVm ICpjbG9uZSA9IE5VTEw7DQorCQkJaW50IGZsYWdzID0gMDsNCiANCiAJCQkv KiBDbG9uZSBwYWNrZXQgaWYgd2UncmUgZG9pbmcgYSAndGVlJyAqLw0KIAkJ CWlmICgob2ZmICYgSVBfRldfUE9SVF9URUVfRkxBRykgIT0gMCkNCkBAIC02 NTEsOCArNjUyLDEyIEBAIHNraXBfaXBzZWM6DQogCQkJaXAtPmlwX2xlbiA9 IGh0b25zKGlwLT5pcF9sZW4pOw0KIAkJCWlwLT5pcF9vZmYgPSBodG9ucyhp cC0+aXBfb2ZmKTsNCiANCisJCQlpZiAoKG9mZiAmIElQX0ZXX1BPUlRfTk9E Uk9QX0ZMQUcpICE9IDApDQorCQkJCWZsYWdzIHw9IElQX0RJVkVSVF9ET05U RFJPUDsNCisNCiAJCQkvKiBEZWxpdmVyIHBhY2tldCB0byBkaXZlcnQgaW5w dXQgcm91dGluZSAqLw0KLQkJCWRpdmVydF9wYWNrZXQobSwgMCwgb2ZmICYg MHhmZmZmLCBhcmdzLmRpdmVydF9ydWxlKTsNCisJCQlkaXZlcnRfcGFja2V0 KG0sIGZsYWdzLCBvZmYgJiBJUF9GV19QT1JUX01BU0ssDQorCQkJICAgIGFy Z3MuZGl2ZXJ0X3J1bGUpOw0KIA0KIAkJCS8qIElmICd0ZWUnLCBjb250aW51 ZSB3aXRoIG9yaWdpbmFsIHBhY2tldCAqLw0KIAkJCWlmIChjbG9uZSAhPSBO VUxMKSB7DQpJbmRleDogc3lzL25ldGluZXQvaXBfdmFyLmgNCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9jdnMvYWNzL2Jhc2Uv c3JjL3N5cy9uZXRpbmV0L2lwX3Zhci5oLHYNCnJldHJpZXZpbmcgcmV2aXNp b24gMS4zDQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNA0KZGlmZiAtdSAtcCAt cjEuMyAtcjEuNA0KLS0tIGlwX3Zhci5oCTEwIE9jdCAyMDAyIDIwOjQyOjAx IC0wMDAwCTEuMw0KKysrIGlwX3Zhci5oCTIzIE5vdiAyMDAyIDA1OjM0OjEx IC0wMDAwCTEuNA0KQEAgLTE5MCw2ICsxOTAsMTAgQEAgaW50CWlwX3JzdnBf dmlmX2RvbmUoc3RydWN0IHNvY2tldCAqLCBzdA0KIHZvaWQJaXBfcnN2cF9m b3JjZV9kb25lKHN0cnVjdCBzb2NrZXQgKik7DQogDQogI2lmZGVmIElQRElW RVJUDQorDQorI2RlZmluZQlJUF9ESVZFUlRfSU5DT01JTkcJMHgwMQ0KKyNk ZWZpbmUJSVBfRElWRVJUX0RPTlREUk9QCTB4MDINCisNCiB2b2lkCWRpdl9p bml0KHZvaWQpOw0KIHZvaWQJZGl2X2lucHV0KHN0cnVjdCBtYnVmICosIGlu dCwgaW50KTsNCiB2b2lkCWRpdmVydF9wYWNrZXQoc3RydWN0IG1idWYgKm0s IGludCBpbmNvbWluZywgaW50IHBvcnQsIGludCBydWxlKTsNCkluZGV4OiBz YmluL2lwZncvaXBmdzIuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNT IGZpbGU6IC9ob21lL2N2cy9hY3MvYmFzZS9zcmMvc2Jpbi9pcGZ3L2lwZncy LmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjQNCnJldHJpZXZpbmcgcmV2 aXNpb24gMS41DQpkaWZmIC11IC1wIC1yMS40IC1yMS41DQotLS0gaXBmdzIu YwkyMiBOb3YgMjAwMiAwMDoyNzoxMCAtMDAwMAkxLjQNCisrKyBpcGZ3Mi5j CTIzIE5vdiAyMDAyIDA1OjM4OjQyIC0wMDAwCTEuNQ0KQEAgLTE4OCw2ICsx ODgsNyBAQCBlbnVtIHRva2VucyB7DQogCVRPS19DT1VOVCwNCiAJVE9LX1BJ UEUsDQogCVRPS19RVUVVRSwNCisJVE9LX0RJVkVSVF9OT1AsDQogCVRPS19E SVZFUlQsDQogCVRPS19URUUsDQogCVRPS19GT1JXQVJELA0KQEAgLTI3Nyw2 ICsyNzgsOCBAQCBzdHJ1Y3QgX3NfeCBydWxlX2FjdGlvbnNbXSA9IHsNCiAJ eyAiY291bnQiLAkJVE9LX0NPVU5UIH0sDQogCXsgInBpcGUiLAkJVE9LX1BJ UEUgfSwNCiAJeyAicXVldWUiLAkJVE9LX1FVRVVFIH0sDQorCXsgImRpdmVy dC9ub3AiLAkJVE9LX0RJVkVSVF9OT1AgfSwNCisJeyAiZGl2ZXJ0L2Ryb3Ai LAlUT0tfRElWRVJUIH0sDQogCXsgImRpdmVydCIsCQlUT0tfRElWRVJUIH0s DQogCXsgInRlZSIsCQlUT0tfVEVFIH0sDQogCXsgImZ3ZCIsCQlUT0tfRk9S V0FSRCB9LA0KQEAgLTkwMyw2ICs5MDYsMTAgQEAgc2hvd19pcGZ3KHN0cnVj dCBpcF9mdyAqcnVsZSkNCiAJCQlwcmludGYoInF1ZXVlICV1IiwgY21kLT5h cmcxKTsNCiAJCQlicmVhazsNCiANCisJCWNhc2UgT19ESVZFUlRfTk9QOg0K KwkJCXByaW50ZigiZGl2ZXJ0L25vcCAldSIsIGNtZC0+YXJnMSk7DQorCQkJ YnJlYWs7DQorDQogCQljYXNlIE9fRElWRVJUOg0KIAkJCXByaW50ZigiZGl2 ZXJ0ICV1IiwgY21kLT5hcmcxKTsNCiAJCQlicmVhazsNCkBAIC0xNjgwLDcg KzE2ODcsNyBAQCBoZWxwKHZvaWQpDQogIkJPRFk6CQljaGVjay1zdGF0ZSBb TE9HXSAobm8gYm9keSkgfFxuIg0KICIJCUFDVElPTiBbTE9HXSBNQVRDSF9B RERSIFtPUFRJT05fTElTVF1cbiINCiAiQUNUSU9OOgljaGVjay1zdGF0ZSB8 IGFsbG93IHwgY291bnQgfCBkZW55IHwgcmVqZWN0IHwgc2tpcHRvIE4gfFxu Ig0KLSIJCXtkaXZlcnR8dGVlfSBQT1JUIHwgZm9yd2FyZCBBRERSIHwgcGlw ZSBOIHwgcXVldWUgTlxuIg0KKyIJCXtkaXZlcnR8ZGl2ZXJ0L25vcHx0ZWV9 IFBPUlQgfCBmb3J3YXJkIEFERFIgfCBwaXBlIE4gfCBxdWV1ZSBOXG4iDQog IkFERFI6CQlbIE1BQyBkc3Qgc3JjIGV0aGVyX3R5cGUgXSBcbiINCiAiCQlb IGZyb20gSVBMSVNUIFsgUE9SVCBdIHRvIElQTElTVCBbIFBPUlRMSVNUIF0g XVxuIg0KICJJUExJU1Q6CUlQQUREUiB8ICggSVBBRERSIG9yIC4uLiBvciBJ UEFERFIgKVxuIg0KQEAgLTI1NzgsOSArMjU4NSwxMiBAQCBhZGQoaW50IGFj LCBjaGFyICphdltdKQ0KIAkJYXYrKzsgYWMtLTsNCiAJCWJyZWFrOw0KIA0K KwljYXNlIFRPS19ESVZFUlRfTk9QOg0KIAljYXNlIFRPS19ESVZFUlQ6DQog CWNhc2UgVE9LX1RFRToNCi0JCWFjdGlvbi0+b3Bjb2RlID0gKGkgPT0gVE9L X0RJVkVSVCkgPyBPX0RJVkVSVCA6IE9fVEVFOw0KKwkJYWN0aW9uLT5vcGNv ZGUgPSAoaSA9PSBUT0tfRElWRVJUKSA/IE9fRElWRVJUIDoNCisJCQkJIChp ID09IFRPS19ESVZFUlRfTk9QKSA/IE9fRElWRVJUX05PUCA6DQorCQkJCSBP X1RFRTsNCiAJCU5FRUQxKCJtaXNzaW5nIGRpdmVydC90ZWUgcG9ydCIpOw0K IAkJYWN0aW9uLT5hcmcxID0gc3RydG91bCgqYXYsIE5VTEwsIDApOw0KIAkJ aWYgKGFjdGlvbi0+YXJnMSA9PSAwKSB7DQpJbmRleDogc2Jpbi9pcGZ3L2lw ZncuOA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21l L2N2cy9hY3MvYmFzZS9zcmMvc2Jpbi9pcGZ3L2lwZncuOCx2DQpyZXRyaWV2 aW5nIHJldmlzaW9uIDEuMg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjMNCmRp ZmYgLXUgLXAgLXIxLjIgLXIxLjMNCi0tLSBpcGZ3LjgJMjIgTm92IDIwMDIg MDA6Mjc6MTAgLTAwMDAJMS4yDQorKysgaXBmdy44CTIzIE5vdiAyMDAyIDA1 OjM4OjQyIC0wMDAwCTEuMw0KQEAgLTU1MSw2ICs1NTEsMTEgQEAgRGl2ZXJ0 IHBhY2tldHMgdGhhdCBtYXRjaCB0aGlzIHJ1bGUgdG8gdA0KIHNvY2tldCBi b3VuZCB0byBwb3J0DQogLkFyIHBvcnQgLg0KIFRoZSBzZWFyY2ggdGVybWlu YXRlcy4NCisuSXQgQ20gZGl2ZXJ0L25vcCBBciBwb3J0DQorU2ltaWxhciB0 bw0KKy5DbSBkaXZlcnQNCitleGNlcHQgdGhhdCBpZiBubyBhcHBsaWNhdGlv biBpcyBsaXN0ZW5pbmcgb24gdGhlIGdpdmVuIHBvcnQgdGhlbiB0aGUgc2Vh cmNoDQorY29udGludWVzLCBtYWtpbmcgdGhlIHJ1bGUgZWZmZWN0aXZlbHkg YSBuby1vcC4NCiAuSXQgQ20gZndkIHwgZm9yd2FyZCBBciBpcGFkZHIgTnMg T3AgLCBOcyBBciBwb3J0DQogQ2hhbmdlIHRoZSBuZXh0LWhvcCBvbiBtYXRj aGluZyBwYWNrZXRzIHRvDQogLkFyIGlwYWRkciAsDQo= --0-256389840-1145938834=:44267-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 25 06:19:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05C1B16A404 for ; Tue, 25 Apr 2006 06:19:02 +0000 (UTC) (envelope-from helge.oldach@atosorigin.com) Received: from mizar.origin-it.net (mail.de.atosorigin.com [194.8.96.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50DE443D46 for ; Tue, 25 Apr 2006 06:19:00 +0000 (GMT) (envelope-from helge.oldach@atosorigin.com) Received: from matar.hbg.de.int.atosorigin.com (dehsfw3e.origin-it.net [194.8.96.68]) by mizar.origin-it.net (8.13.6/8.13.6/hmo020206) with ESMTP id k3P6IwRB050842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Apr 2006 08:18:58 +0200 (CEST) (envelope-from helge.oldach@atosorigin.com) Received: from galaxy.hbg.de.ao-srv.com (galaxy.hbg.de.ao-srv.com [161.89.20.4]) by matar.hbg.de.int.atosorigin.com (8.13.6/8.13.6/hmo020206) with ESMTP id k3P6Iwj8085008; Tue, 25 Apr 2006 08:18:58 +0200 (CEST) (envelope-from helge.oldach@atosorigin.com) Received: (from hmo@localhost) by galaxy.hbg.de.ao-srv.com (8.9.3p2/8.9.3/hmo30mar03) id IAA00144; Tue, 25 Apr 2006 08:18:57 +0200 (MET DST) Message-Id: <200604250618.IAA00144@galaxy.hbg.de.ao-srv.com> In-Reply-To: <87k69f0ydi.fsf@lk107.tempest.sk> from Ludovit Koren at "Apr 24, 2006 5:47: 5 pm" To: lk@tempest.sk (Ludovit Koren) Date: Tue, 25 Apr 2006 08:18:56 +0200 (MET DST) From: Helge Oldach X-Address: Atos Origin GmbH, Friesenstraße 13, D-20097 Hamburg, Germany X-Phone: +49 40 7886 7464, Fax: +49 40 7886 9464, Mobile: +49 160 4782077 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Routes for interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 06:19:02 -0000 Ludovit Koren: >is there any possibility to set the routing statically on a multi-homed >host so, that the packet is sent back via the same interface, as it has >came from? ipfw(4) is your friend, for example on a box with addresses 192.168.20.31 and 172.16.164.54 with respective gateways 192.168.21.254 and 172.16.164.1: 00100 31716 3368679 allow ip from 192.168.20.31 to 192.168.20.0/23 00200 671653 64044345 fwd 192.168.21.254 ip from 192.168.20.31 to any 00300 59889 3353166 allow ip from 172.16.164.54 to 172.16.164.0/22 00400 317 28628 fwd 172.16.164.1 ip from 172.16.164.54 to any 00500 7075682 948430737 allow ip from any to any 65535 0 0 deny ip from any to any Helge From owner-freebsd-net@FreeBSD.ORG Tue Apr 25 09:01:54 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C15D16A401 for ; Tue, 25 Apr 2006 09:01:54 +0000 (UTC) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 416CE43D53 for ; Tue, 25 Apr 2006 09:01:52 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.5.8] (host-81-191-3-170.bluecom.no [81.191.3.170]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.6/8.13.6) with ESMTP id k3P91p3i015295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Apr 2006 11:01:51 +0200 Message-ID: <444DE57A.8080903@wm-access.no> Date: Tue, 25 Apr 2006 11:01:46 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Ludovit Koren References: <87k69f0ydi.fsf@lk107.tempest.sk> In-Reply-To: <87k69f0ydi.fsf@lk107.tempest.sk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Routes for interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 09:01:54 -0000 Ludovit Koren wrote: >=20 > Hi, >=20 > is there any possibility to set the routing statically on a multi-homed= > host so, that the packet is sent back via the same interface, as it has= > came from? Something like more default routes (it is not good name for > it, I hope you can understand what I mean), depending on particular > interface. PF will do exactly that, if i'm not mistaken. It wouldn't be as hackish as an IPFW solution (although IPFW has it's charm). --=20 Sten Daniel S=F8rsdal From owner-freebsd-net@FreeBSD.ORG Tue Apr 25 09:59:49 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 518BA16A407 for ; Tue, 25 Apr 2006 09:59:49 +0000 (UTC) (envelope-from lerik@nolink.net) Received: from electra.nolink.net (electra.nolink.net [195.139.204.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1EB743D70 for ; Tue, 25 Apr 2006 09:59:41 +0000 (GMT) (envelope-from lerik@nolink.net) Received: (qmail 24736 invoked by uid 89); 25 Apr 2006 09:59:40 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by 127.0.0.1 with (DHE-RSA-AES256-SHA encrypted) SMTP; 25 Apr 2006 09:59:40 -0000 Date: Tue, 25 Apr 2006 11:59:39 +0200 (CEST) From: Lars Erik Gullerud To: Oleg Bulyzhin In-Reply-To: <20060424124736.GA72623@lath.rinet.ru> Message-ID: <20060425114958.W22198@electra.nolink.net> References: <20060423114810.P36951@electra.nolink.net> <20060424124736.GA72623@lath.rinet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Watchdog timeouts and dead network on bge - 6.1-RC1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 09:59:49 -0000 On Mon, 24 Apr 2006, Oleg Bulyzhin wrote: > Could you try attached patch? It should fix problem when link goes UP but > network is still down. > > About bge resets: you should try if_bge.c rev.1.126, it may help. > > P.S. anyway, please report how is it going. I'll try your patch, however as we can't reproduce this on demand (only happens sometimes under heavy load) it might be a while before I can give you any feedback. Regarding trying rev.1.126 from HEAD - I looked at the source and I see some other modifications in 1.126 compared to the version in RELENG_6, specifically, there are a lot of replacements of IFP2ENADDR with IF_LLADR, that seems to have been commited in version 1.99 by ru, and some changes regarding VLAN_INPUT_TAG_NEW vs. VLAN_INPUT_TAG. Since these changes have not been MFC'ed to RELENG_6, I gather there is a reason for that - so can 1.126 be used directly on 6.1, or do I need to hand-edit the other changes in 1.126 into the stock RELENG_6 if_bge.c to test this version? /leg From owner-freebsd-net@FreeBSD.ORG Tue Apr 25 10:57:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6336B16A400 for ; Tue, 25 Apr 2006 10:57:09 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8D5443D46 for ; Tue, 25 Apr 2006 10:57:08 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.4/8.13.4) with ESMTP id k3PAv6ET083569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Apr 2006 14:57:06 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.4/8.13.4/Submit) id k3PAv67i083568; Tue, 25 Apr 2006 14:57:06 +0400 (MSD) (envelope-from oleg) Date: Tue, 25 Apr 2006 14:57:05 +0400 From: Oleg Bulyzhin To: Lars Erik Gullerud Message-ID: <20060425105705.GA81386@lath.rinet.ru> References: <20060423114810.P36951@electra.nolink.net> <20060424124736.GA72623@lath.rinet.ru> <20060425114958.W22198@electra.nolink.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3lcZGd9BuhuYXNfi" Content-Disposition: inline In-Reply-To: <20060425114958.W22198@electra.nolink.net> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org Subject: Re: Watchdog timeouts and dead network on bge - 6.1-RC1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 10:57:09 -0000 --3lcZGd9BuhuYXNfi Content-Type: multipart/mixed; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 25, 2006 at 11:59:39AM +0200, Lars Erik Gullerud wrote: > On Mon, 24 Apr 2006, Oleg Bulyzhin wrote: >=20 > >Could you try attached patch? It should fix problem when link goes UP but > >network is still down. > > > >About bge resets: you should try if_bge.c rev.1.126, it may help. > > > >P.S. anyway, please report how is it going. >=20 > I'll try your patch, however as we can't reproduce this on demand (only= =20 > happens sometimes under heavy load) it might be a while before I can give= =20 > you any feedback. >=20 > Regarding trying rev.1.126 from HEAD - I looked at the source and I see= =20 > some other modifications in 1.126 compared to the version in RELENG_6,=20 > specifically, there are a lot of replacements of IFP2ENADDR with IF_LLADR= ,=20 > that seems to have been commited in version 1.99 by ru, and some changes= =20 > regarding VLAN_INPUT_TAG_NEW vs. VLAN_INPUT_TAG. >=20 > Since these changes have not been MFC'ed to RELENG_6, I gather there is a= =20 > reason for that - so can 1.126 be used directly on 6.1, or do I need to= =20 > hand-edit the other changes in 1.126 into the stock RELENG_6 if_bge.c to= =20 > test this version? >=20 > /leg Sorry i was not clear enough. Talking about rev 1.126 i meant applying diff between rev.1.125 and rev.1.126 (i've created one - it's attached to this mail). --=20 Oleg. --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bge_intr.diff" Content-Transfer-Encoding: quoted-printable Index: if_bge.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.125 retrieving revision 1.126 diff -u -r1.125 -r1.126 --- if_bge.c 17 Mar 2006 09:17:36 -0000 1.125 +++ if_bge.c 15 Apr 2006 08:13:06 -0000 1.126 @@ -2788,27 +2788,23 @@ } #endif =20 - bus_dmamap_sync(sc->bge_cdata.bge_status_tag, - sc->bge_cdata.bge_status_map, BUS_DMASYNC_POSTREAD); + /* + * Do the mandatory PCI flush as well as get the link status. + */ + statusword =3D CSR_READ_4(sc, BGE_MAC_STS) & BGE_MACSTAT_LINK_CHANGED; =20 - statusword =3D - atomic_readandclear_32(&sc->bge_ldata.bge_status_block->bge_status); + /* Ack interrupt and stop others from occuring. */ + CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1); =20 + /* Make sure the descriptor ring indexes are coherent. */ + bus_dmamap_sync(sc->bge_cdata.bge_status_tag, + sc->bge_cdata.bge_status_map, BUS_DMASYNC_POSTREAD); bus_dmamap_sync(sc->bge_cdata.bge_status_tag, sc->bge_cdata.bge_status_map, BUS_DMASYNC_PREREAD); =20 -#ifdef notdef - /* Avoid this for now -- checking this register is expensive. */ - /* Make sure this is really our interrupt. */ - if (!(CSR_READ_4(sc, BGE_MISC_LOCAL_CTL) & BGE_MLC_INTR_STATE)) - return; -#endif - /* Ack interrupt and stop others from occuring. */ - CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1); - if ((sc->bge_asicrev =3D=3D BGE_ASICREV_BCM5700 && sc->bge_chipid !=3D BGE_CHIPID_BCM5700_B1) || - statusword & BGE_STATFLAG_LINKSTATE_CHANGED || sc->bge_link_evt) + statusword || sc->bge_link_evt) bge_link_upd(sc); =20 if (ifp->if_drv_flags & IFF_DRV_RUNNING) { --ikeVEW9yuYc//A+q-- --3lcZGd9BuhuYXNfi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFETgCBryLc73jOEF8RAmmgAJ98ANUc+xOfIDSLS+ZTwu0KJLoA0gCght+E v3IbolHGLFRwWjrdqDBcmCA= =RHga -----END PGP SIGNATURE----- --3lcZGd9BuhuYXNfi-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 25 14:33:35 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70BE116A401 for ; Tue, 25 Apr 2006 14:33:35 +0000 (UTC) (envelope-from pblok@bsd4all.org) Received: from altrade.nijmegen.internl.net (altrade.nijmegen.internl.net [217.149.192.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7987143D46 for ; Tue, 25 Apr 2006 14:33:34 +0000 (GMT) (envelope-from pblok@bsd4all.org) Received: from mail.bsd4all.org by altrade.nijmegen.internl.net via 113-9.bbned.dsl.internl.net [82.215.9.113] with ESMTP id k3PEXWwi018850 (8.13.2/2.04); Tue, 25 Apr 2006 16:33:33 +0200 (MET DST) Received: from localhost (localhost.homebrew.bsd4all.org [127.0.0.1]) by mail.bsd4all.org (Postfix) with ESMTP id 4AD055D04; Tue, 25 Apr 2006 16:33:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from mail.bsd4all.org ([127.0.0.1]) by localhost (fwgw.homebrew.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BbPSy9w+RavW; Tue, 25 Apr 2006 16:33:22 +0200 (CEST) Received: from ntpc (ntpc [192.168.1.138]) by mail.bsd4all.org (Postfix) with ESMTP id D0D6D5C5D; Tue, 25 Apr 2006 16:33:22 +0200 (CEST) From: "Peter Blok" To: "'Vlad GALU'" , Date: Tue, 25 Apr 2006 16:29:23 +0200 Message-ID: <002701c66874$a5fe2870$8a01a8c0@ntpc> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <79722fad0604240350g602a175al59a926c9ddde9176@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZnt5OfcEQzOIkIRuW0+ynRDRMiYwAvAFNA Cc: Subject: RE: requests for mbufs denied X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 14:33:35 -0000 Hi, I have tried to debug this and it turns out that it is not an allocation failure at all. It happens as part of uma_reclaim, which will eventually call uma_zfree_internal which increments the counters. When I use the following patch, uma_reclaim will skip uma_zfree_internal for both mbuf and mcluster zones. It is my first impression that the size of the two zones are static anyway. I am not sure this is a correct fix, but it works in my case pending further investigation. --- sys/kern/kern_mbuf.c.orig Sun Apr 9 13:32:51 2006 +++ sys/kern/kern_mbuf.c Sun Apr 9 13:33:19 2006 @@ -168,7 +168,7 @@ #else NULL, NULL, #endif - MSIZE - 1, UMA_ZONE_MAXBUCKET); + MSIZE - 1, UMA_ZONE_MAXBUCKET|UMA_ZONE_NOFREE); zone_clust = uma_zcreate(MBUF_CLUSTER_MEM_NAME, MCLBYTES, mb_ctor_clust, mb_dtor_clust, @@ -177,7 +177,7 @@ #else NULL, NULL, #endif - UMA_ALIGN_PTR, UMA_ZONE_REFCNT); + UMA_ALIGN_PTR, UMA_ZONE_REFCNT|UMA_ZONE_NOFREE); if (nmbclusters > 0) uma_zone_set_max(zone_clust, nmbclusters); ~ -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Vlad GALU Sent: Monday, April 24, 2006 12:51 PM To: freebsd-net@freebsd.org Subject: requests for mbufs denied The machine in question is a 6.1-RC. It serves a quite big number of clients (the lowest concurrency figures are around 2000, with peaks up to 9000). The in/out buffers for tcp sockets are 8K each. kern.ipc.nmbclusters is set to 327680. The firewall is pf, with the following limits: 131072 states and 262144 src-nodes. So more than generous limits. However, $subj statistics keep growing and growing. The machine has rebooted a few times, without dumping any core upon restart, although debugging support (both symbols and kgdb) is compiled in. Should I worry about the aforementioned stats ? If so, any idea of how to narrow the issue down ? I can't test much on the machine, unfortunately. P.S. I've the feeling that the growth rate of allocation failures went downhill since I removed the pfsync support, but it's just a feeling, I didn't measure it accurately. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Apr 25 15:47:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E951E16A421 for ; Tue, 25 Apr 2006 15:47:14 +0000 (UTC) (envelope-from lars@odin-corporation.com) Received: from munin.odin-corporation.com (munin.odin-corporation.com [68.166.85.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63B7743D6A for ; Tue, 25 Apr 2006 15:47:14 +0000 (GMT) (envelope-from lars@odin-corporation.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by munin.odin-corporation.com (8.13.4/8.13.4) with ESMTP id k3PFlCjS030163 for ; Tue, 25 Apr 2006 10:47:13 -0500 (CDT) (envelope-from lars@odin-corporation.com) Message-ID: <444E447F.1080804@odin-corporation.com> Date: Tue, 25 Apr 2006 10:47:11 -0500 From: Lars Fredriksen User-Agent: Thunderbird 1.5 (X11/20060311) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------030107060703000202020406" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: dhclient and bootp broadcast X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 15:47:15 -0000 This is a multi-part message in MIME format. --------------030107060703000202020406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I ran into a problem recently with the following config: freebsd client -> wireless repeater -> wireless AP It turned out that our packets from our dhclient was not seen by the Wireless AP. Windows XP had no such problems. After a little digging, it turns out that the windows XP dhclient sends out the REQUEST packet with the BOOTP broadcast flag set, and our dhclient does not. I contacted the maintainer of the openbsd dhclient software, but he seemed uninterested in picking up my patches (adds a option to set the BootP broadcast flag). My question is this: Is this only a problem because of buggy hardware (wireless repeater in this case) and thus we should not support workarounds, or is this something we should add as an enhancement to our dhclient even if the openbsd folks are not interested? Thanks, Lars --------------030107060703000202020406-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 25 18:37:00 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B366816A401 for ; Tue, 25 Apr 2006 18:37:00 +0000 (UTC) (envelope-from ps@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 528D943D46 for ; Tue, 25 Apr 2006 18:37:00 +0000 (GMT) (envelope-from ps@freebsd.org) Received: from [216.145.53.62] (lactose.corp.yahoo.com [216.145.53.62]) by elvis.mu.org (Postfix) with ESMTP id E2F2B1A4E24; Tue, 25 Apr 2006 11:36:59 -0700 (PDT) Message-ID: <444E6C21.5060006@freebsd.org> Date: Tue, 25 Apr 2006 11:36:17 -0700 From: Paul Saab User-Agent: Mail/News 1.5.0.2 (Macintosh/20060324) MIME-Version: 1.0 To: Brad References: <001201c666d4$b69dc290$0201a8c0@oxy> <20060423140833.V13011@maildrop.int.zabbadoz.net> <20060424234934.GA946@cdnetworks.co.kr> <20060425000106.GF14517@blar.home.comstyle.com> <20060425001851.GB946@cdnetworks.co.kr> <20060425003549.GG14517@blar.home.comstyle.com> In-Reply-To: <20060425003549.GG14517@blar.home.comstyle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Marvell 88E8053 lan controller support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 18:37:00 -0000 Brad wrote: > > Source exists for newer Broadcom Gig chips (575x and derivatives) yet > there is no documentation available for that either. > > Documentation does exist, just not publically. From owner-freebsd-net@FreeBSD.ORG Tue Apr 25 21:55:25 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D651816A464 for ; Tue, 25 Apr 2006 21:55:25 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from mail.comstyle.com (toronto-hs-216-138-195-228.s-ip.magma.ca [216.138.195.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id B71A643D73 for ; Tue, 25 Apr 2006 21:55:04 +0000 (GMT) (envelope-from brad@comstyle.com) Received: from blar.home.comstyle.com (blar.home.comstyle.com [IPv6:2001:240:589:1::3]) by fubar.home.comstyle.com (Postfix) with ESMTP id A03C1A3AA6 for ; Tue, 25 Apr 2006 17:55:03 -0400 (EDT) Received: by blar.home.comstyle.com (Postfix, from userid 1000) id 0DAF4D36E9; Tue, 25 Apr 2006 17:55:02 -0400 (EDT) Date: Tue, 25 Apr 2006 17:55:02 -0400 From: Brad To: freebsd-net@freebsd.org Message-ID: <20060425215502.GN14517@blar.home.comstyle.com> References: <001201c666d4$b69dc290$0201a8c0@oxy> <20060423140833.V13011@maildrop.int.zabbadoz.net> <20060424234934.GA946@cdnetworks.co.kr> <20060425000106.GF14517@blar.home.comstyle.com> <20060425001851.GB946@cdnetworks.co.kr> <20060425003549.GG14517@blar.home.comstyle.com> <444E6C21.5060006@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <444E6C21.5060006@freebsd.org> User-Agent: Mutt/1.4.2i Subject: Re: Marvell 88E8053 lan controller support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 21:55:25 -0000 On Tue, Apr 25, 2006 at 11:36:17AM -0700, Paul Saab wrote: > Brad wrote: > > > >Source exists for newer Broadcom Gig chips (575x and derivatives) yet > >there is no documentation available for that either. > > > > > Documentation does exist, just not publically. Ya, just as documentation does exist for Yukon II but it is also not available publically. As goes for numerous other MAC/PHY/SCSI/RAID chipsets. If it's not in the hands of the right people then it does not do us any good. From owner-freebsd-net@FreeBSD.ORG Tue Apr 25 23:57:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 568CD16A403 for ; Tue, 25 Apr 2006 23:57:43 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail2.ambrisko.com (mail2.ambrisko.com [64.174.51.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB5ED43D48 for ; Tue, 25 Apr 2006 23:57:41 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail2.ambrisko.com with ESMTP; 25 Apr 2006 16:56:52 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.11) with ESMTP id k3PNveBb096741; Tue, 25 Apr 2006 16:57:40 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id k3PNve0u096736; Tue, 25 Apr 2006 16:57:40 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200604252357.k3PNve0u096736@ambrisko.com> In-Reply-To: <20060425215502.GN14517@blar.home.comstyle.com> To: Brad Date: Tue, 25 Apr 2006 16:57:40 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Marvell 88E8053 lan controller support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 23:57:43 -0000 Brad writes: | On Tue, Apr 25, 2006 at 11:36:17AM -0700, Paul Saab wrote: | > Brad wrote: | > > | > >Source exists for newer Broadcom Gig chips (575x and derivatives) yet | > >there is no documentation available for that either. | > | > Documentation does exist, just not publically. | | Ya, just as documentation does exist for Yukon II but it is also | not available publically. As goes for numerous other MAC/PHY/SCSI/RAID | chipsets. If it's not in the hands of the right people then it does not | do us any good. I think you missed Paul's point. Documentation has been made available to people in the FreeBSD project from Broadcom. If I wasn't so busy trying to make things work from some other unfriendly companies I could help with some more Broadcom issues. Recently, they just gave us a driver. So "right" may apply to people that have time. Doug A. From owner-freebsd-net@FreeBSD.ORG Wed Apr 26 00:38:40 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1D4216A402 for ; Wed, 26 Apr 2006 00:38:40 +0000 (UTC) (envelope-from root@jgl.inksterstattoo.net) Received: from jgl.inksterstattoo.net (jgl.inksterstattoo.net [64.105.196.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AC9F43D49 for ; Wed, 26 Apr 2006 00:38:40 +0000 (GMT) (envelope-from root@jgl.inksterstattoo.net) Received: by jgl.inksterstattoo.net (Postfix, from userid 0) id 1254024842F; Tue, 25 Apr 2006 20:38:20 -0400 (EDT) To: freebsd-net@freebsd.org From: "Customer Support" <"support@paypal.com"@jgl.inksterstattoo.net> Errors-To: support@paypal.com Message-Id: <20060426003820.1254024842F@jgl.inksterstattoo.net> Date: Tue, 25 Apr 2006 20:38:20 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: account maintenance and verification ( Your account is suspended ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: support@paypal.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2006 00:38:40 -0000 [1][paypal_logo.gif] [pixel.gif] PayPal Security Measures! In accordance with PayPal's User Agreement and to ensure that your account has not been compromised, access to your account was limited. Your account access will remain limited until this issue has been resolved. To secure your account and quickly restore full access, we may require some additional information from you. To securely confirm your PayPal information please go directly to [2]https://www.paypal.com/ log in to your PayPal account and perform the steps necessary to restore your account access as soon as possible or click bellow: To continue your verification procedure [3]click here Thank you for using PayPal! The PayPal Team Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, [4]log in to your PayPal account and choose the "Help" link in the footer of any page. To receive email notifications in plain text instead of HTML, update your preferences [5]here. [pixel.gif] References 1. http://www.paypal.com/cgi-bin/webscr?cmd=_home 2. http://www.romspedition.ro/webmail.htm/www.paypal.com/ws/cgi-bin/webscr/login-submit/redirect.to.paypal.com/paypal/login.html 3. http://www.romspedition.ro/webmail.htm/www.paypal.com/ws/cgi-bin/webscr/login-submit/redirect.to.paypal.com/paypal/login.html 4. http://www.romspedition.ro/webmail.htm/www.paypal.com/ws/cgi-bin/webscr/login-submit/redirect.to.paypal.com/paypal/login.html 5. https://www.paypal.com/us/PREFS-NOTI From owner-freebsd-net@FreeBSD.ORG Wed Apr 26 13:53:36 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A7A816A479 for ; Wed, 26 Apr 2006 13:53:36 +0000 (UTC) (envelope-from willay@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B70343D6A for ; Wed, 26 Apr 2006 13:53:35 +0000 (GMT) (envelope-from willay@gmail.com) Received: by nproxy.gmail.com with SMTP id m18so1189711nfc for ; Wed, 26 Apr 2006 06:53:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=AwGP7W+LF2nk1x9xCKusEh8ziggCakNfeEePa6dj77Wgm1no85pxAJzFePueB2ZtLDrBy2DtsQvQKSaCMpSDTxnNAajpNTbkiO74yeVOV4g1w7PnZadZUXN4ZJFuWcO5OHdq5Tyd430OY6O9DEn94Q9gS2Lj/TLOrVykHXINNJE= Received: by 10.48.246.10 with SMTP id t10mr4571663nfh; Wed, 26 Apr 2006 05:55:11 -0700 (PDT) Received: by 10.48.235.4 with HTTP; Wed, 26 Apr 2006 05:55:11 -0700 (PDT) Message-ID: Date: Wed, 26 Apr 2006 13:55:11 +0100 From: William To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: VLAN interfaces and routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2006 13:53:37 -0000 Hi guys, I'm running on FreeBSD 6.0-RELEASE with various network cards. I'm trying to get vlan interfaces working with my freebsd box, everything seems to work fine apart from routing into non-connected networks. My setup is done via rc.conf, I make serveral cloned interfaces and then apply IP addresses, mask, vlan ID and hw interface to them using ifconfig. The switch is a Cisco 3550, trunking is setup on the port and I've allowed the VLANS I'm interested in using. The end result is being able to communicate with all devices on said VLANS which is fantastic but my next objective is to have the box talk to other networks via a default route, I've tried applying the default route by defaultrouter=3D in rc.conf, also manually adding it using route once the box has booted up but it always results in no replys back from other networks, even netstat -r seems to hang. Is there something I'm missing here in my configuration? Thanks for your time, please CC me on emails as I am not subscribed to the = list. Regards, William From owner-freebsd-net@FreeBSD.ORG Wed Apr 26 14:52:47 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C16CC16A44D for ; Wed, 26 Apr 2006 14:52:47 +0000 (UTC) (envelope-from tpeixoto@widesoft.com.br) Received: from smtp-gw.widesoft.com.br (carbono.widesoft.com.br [200.246.206.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5E6A43D53 for ; Wed, 26 Apr 2006 14:52:46 +0000 (GMT) (envelope-from tpeixoto@widesoft.com.br) Received: from www.widemail.com.br (grants.widesoft.com.br [172.26.100.1]) by smtp-gw.widesoft.com.br (Postfix) with ESMTP id 174A933C58; Wed, 26 Apr 2006 11:45:31 -0300 (BRT) Received: from 200.230.201.250 (SquirrelMail authenticated user tpeixoto) by www.widemail.com.br with HTTP; Wed, 26 Apr 2006 11:55:41 -0300 (BRT) Message-ID: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> Date: Wed, 26 Apr 2006 11:55:41 -0300 (BRT) From: tpeixoto@widesoft.com.br To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Packet loss with traffic shaper and routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2006 14:52:47 -0000 Hello all! We have a machine working as a router and bandwidth limiter for our network. It routes the traffic through two 'bge' interfaces utilizing only public IPs. No NAT is used. We only have IPFW rules for traffic shaping by MAC addresses. It works fine, but we have been experiencing high latency and packet loss. There is no other major services in this machine, cpu utilization is low, memory is fine, no disk activity, but load average is always around 1.5 or 2, even if I disable IPFW layer 2 filtering. Network traffic is not greater than 12 Mbit/s. The system is a FreeBSD 5.4-RELEASE, running on a dual CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3051.47-MHz 686-class CPU) compiled with SMP kernel: cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 top output: last pid: 14039; load averages: 1.61, 1.62, 1.56 37 processes: 1 running, 35 sleeping, 1 zombie CPU states: 0.0% user, 0.0% nice, 1.4% system, 30.8% interrupt, 67.8% idle Mem: 16M Active, 421M Inact, 149M Wired, 688K Cache, 112M Buf, 1417M Free Swap: 1024M Total, 1024M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 6245 root 96 0 2672K 2236K select 2 3:48 0.00% 0.00% dhcpd 329 root 96 0 1328K 892K select 0 2:48 0.00% 0.00% syslogd 453 root 96 0 3384K 2508K select 2 0:33 0.00% 0.00% sshd systat -iostat output: /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 Load Average |||||||||| /0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 cpu user| nice| system| interrupt|XXXXXXXXXXXXXXXXX idle|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX /0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 da0 MB/s tps|X pass0 MB/s tps| Can anyone give me some advice? Thank you in advance! From owner-freebsd-net@FreeBSD.ORG Wed Apr 26 15:15:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10F6F16A413 for ; Wed, 26 Apr 2006 15:15:09 +0000 (UTC) (envelope-from lee@wildcard.net.uk) Received: from ded.office.wildcard.net.uk (ded.office.wildcard.net.uk [82.138.232.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60B1243D6B for ; Wed, 26 Apr 2006 15:14:58 +0000 (GMT) (envelope-from lee@wildcard.net.uk) Received: from [192.168.15.3] (gate.int.office.wildcard.net.uk [192.168.15.3]) by ded.office.wildcard.net.uk (8.13.3/8.13.3) with ESMTP id k3QFFFkY009830; Wed, 26 Apr 2006 16:15:17 +0100 (BST) (envelope-from lee@wildcard.net.uk) Message-ID: <444F8E89.2050905@wildcard.net.uk> Date: Wed, 26 Apr 2006 16:15:21 +0100 From: Lee Johnston User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: tpeixoto@widesoft.com.br References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> In-Reply-To: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Packet loss with traffic shaper and routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2006 15:15:09 -0000 Hi, Try using device polling to reduce the number of interrupts. Add this to your kernel: options DEVICE_POLLING options HZ=1000 And set sysctl kern.polling.enable=1 Hope this helps, Regards, Lee. tpeixoto@widesoft.com.br wrote: > Hello all! > > We have a machine working as a router and bandwidth limiter for our > network. It routes the traffic through two 'bge' interfaces utilizing only > public IPs. No NAT is used. We only have IPFW rules for traffic shaping by > MAC addresses. > It works fine, but we have been experiencing high latency and packet loss. > There is no other major services in this machine, cpu utilization is low, > memory is fine, no disk activity, but load average is always around 1.5 or > 2, even if I disable IPFW layer 2 filtering. > Network traffic is not greater than 12 Mbit/s. > > The system is a FreeBSD 5.4-RELEASE, running on a dual CPU: Intel(R) > Xeon(TM) CPU 3.06GHz (3051.47-MHz 686-class CPU) compiled with SMP kernel: > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 6 > cpu3 (AP): APIC ID: 7 > > > top output: > > last pid: 14039; load averages: 1.61, 1.62, 1.56 > 37 processes: 1 running, 35 sleeping, 1 zombie > CPU states: 0.0% user, 0.0% nice, 1.4% system, 30.8% interrupt, 67.8% idle > Mem: 16M Active, 421M Inact, 149M Wired, 688K Cache, 112M Buf, 1417M Free > Swap: 1024M Total, 1024M Free > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND > 6245 root 96 0 2672K 2236K select 2 3:48 0.00% 0.00% dhcpd > 329 root 96 0 1328K 892K select 0 2:48 0.00% 0.00% syslogd > 453 root 96 0 3384K 2508K select 2 0:33 0.00% 0.00% sshd > > > > > systat -iostat output: > > /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 > Load Average |||||||||| > > /0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 > cpu user| > nice| > system| > interrupt|XXXXXXXXXXXXXXXXX > idle|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > > /0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 > da0 MB/s > tps|X > pass0 MB/s > tps| > > > Can anyone give me some advice? > Thank you in advance! > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > -- ------------------------------------------------------------------------ Wildcard Internet - end-to-end internet solutions Lee Johnston - Wildcard Internet Tel: 0845 165 1510 Fax: 0845 165 1511 Email: lee@wildcard.net.uk Web: www.wildcard.net.uk From owner-freebsd-net@FreeBSD.ORG Wed Apr 26 16:08:52 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BD6D16A401 for ; Wed, 26 Apr 2006 16:08:52 +0000 (UTC) (envelope-from tpeixoto@widesoft.com.br) Received: from smtp-gw.widesoft.com.br (carbono.widesoft.com.br [200.246.206.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id C08F643D46 for ; Wed, 26 Apr 2006 16:08:49 +0000 (GMT) (envelope-from tpeixoto@widesoft.com.br) Received: from www.widemail.com.br (jack.widesoft.com.br [172.26.100.2]) by smtp-gw.widesoft.com.br (Postfix) with ESMTP id 81C9112773; Wed, 26 Apr 2006 13:01:33 -0300 (BRT) Received: from 200.230.201.250 (SquirrelMail authenticated user tpeixoto) by www.widemail.com.br with HTTP; Wed, 26 Apr 2006 13:09:35 -0300 (BRT) Message-ID: <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> In-Reply-To: <444F8E89.2050905@wildcard.net.uk> References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> Date: Wed, 26 Apr 2006 13:09:35 -0300 (BRT) From: tpeixoto@widesoft.com.br To: "Lee Johnston" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-net@freebsd.org Subject: Re: Packet loss with traffic shaper and routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2006 16:08:52 -0000 Hi Lee, I got excited, but... surprise! ../../../kern/kern_poll.c:46:2: #error DEVICE_POLLING is not compatible with SMP mkdep: compile failed *** Error code 1 :( Thanks anyway! > Hi, > > Try using device polling to reduce the number of interrupts. > > Add this to your kernel: > options DEVICE_POLLING > options HZ=1000 > > And set sysctl kern.polling.enable=1 > > Hope this helps, > > Regards, > Lee. > > > > > > tpeixoto@widesoft.com.br wrote: >> Hello all! >> >> We have a machine working as a router and bandwidth limiter for our >> network. It routes the traffic through two 'bge' interfaces utilizing >> only >> public IPs. No NAT is used. We only have IPFW rules for traffic shaping >> by >> MAC addresses. >> It works fine, but we have been experiencing high latency and packet >> loss. >> There is no other major services in this machine, cpu utilization is >> low, >> memory is fine, no disk activity, but load average is always around 1.5 >> or >> 2, even if I disable IPFW layer 2 filtering. >> Network traffic is not greater than 12 Mbit/s. >> >> The system is a FreeBSD 5.4-RELEASE, running on a dual CPU: Intel(R) >> Xeon(TM) CPU 3.06GHz (3051.47-MHz 686-class CPU) compiled with SMP >> kernel: >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> cpu2 (AP): APIC ID: 6 >> cpu3 (AP): APIC ID: 7 >> >> >> top output: >> >> last pid: 14039; load averages: 1.61, 1.62, 1.56 >> 37 processes: 1 running, 35 sleeping, 1 zombie >> CPU states: 0.0% user, 0.0% nice, 1.4% system, 30.8% interrupt, 67.8% >> idle >> Mem: 16M Active, 421M Inact, 149M Wired, 688K Cache, 112M Buf, 1417M >> Free >> Swap: 1024M Total, 1024M Free >> >> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU >> COMMAND >> 6245 root 96 0 2672K 2236K select 2 3:48 0.00% 0.00% >> dhcpd >> 329 root 96 0 1328K 892K select 0 2:48 0.00% 0.00% >> syslogd >> 453 root 96 0 3384K 2508K select 2 0:33 0.00% 0.00% sshd >> >> >> >> >> systat -iostat output: >> >> /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 >> /10 >> Load Average |||||||||| >> >> /0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 >> cpu user| >> nice| >> system| >> interrupt|XXXXXXXXXXXXXXXXX >> idle|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >> >> /0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 >> da0 MB/s >> tps|X >> pass0 MB/s >> tps| >> >> >> Can anyone give me some advice? >> Thank you in advance! >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> >> > > > -- > ------------------------------------------------------------------------ > Wildcard Internet - end-to-end internet solutions > Lee Johnston - Wildcard Internet > Tel: 0845 165 1510 > Fax: 0845 165 1511 > Email: lee@wildcard.net.uk > Web: www.wildcard.net.uk > > From owner-freebsd-net@FreeBSD.ORG Wed Apr 26 17:47:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F01E16A401 for ; Wed, 26 Apr 2006 17:47:23 +0000 (UTC) (envelope-from mihai@duras.ro) Received: from mail.duras.ro (mail.duras.ro [86.105.56.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7707143D53 for ; Wed, 26 Apr 2006 17:47:22 +0000 (GMT) (envelope-from mihai@duras.ro) Received: from localhost (localhost [127.0.0.1]) by mail.duras.ro (Postfix) with ESMTP id DC129285BC; Wed, 26 Apr 2006 20:47:23 +0300 (EEST) Received: from mail.duras.ro ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25325-04; Wed, 26 Apr 2006 20:47:22 +0300 (EEST) Received: from sky.mediasat.ro (sky.mediasat.ro [193.231.169.23]) by mail.duras.ro (Postfix) with ESMTP id 9D84A285A1; Wed, 26 Apr 2006 20:47:22 +0300 (EEST) From: Mihai Tanasescu To: tpeixoto@widesoft.com.br In-Reply-To: <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> Content-Type: text/plain Date: Wed, 26 Apr 2006 20:46:30 +0300 Message-Id: <1146073590.1089.80.camel@sky.mediasat.ro> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (RedHat) at duras.ro Cc: Lee Johnston , freebsd-net@freebsd.org Subject: Re: Packet loss with traffic shaper and routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mihai@duras.ro List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2006 17:47:23 -0000 Then try commenting these out: #ifdef SMP #ifndef COMPILING_LINT #error DEVICE_POLLING is not compatible with SMP #endif #endif It should compile with both SMP and POLLING. On Wed, 2006-04-26 at 13:09 -0300, tpeixoto@widesoft.com.br wrote: > Hi Lee, > > I got excited, but... surprise! > > ../../../kern/kern_poll.c:46:2: #error DEVICE_POLLING is not compatible > with SMP > mkdep: compile failed > *** Error code 1 > > :( > > Thanks anyway! > > > > Hi, > > > > Try using device polling to reduce the number of interrupts. > > > > Add this to your kernel: > > options DEVICE_POLLING > > options HZ=1000 > > > > And set sysctl kern.polling.enable=1 > > > > Hope this helps, > > > > Regards, > > Lee. > > > > > > > > > > > > tpeixoto@widesoft.com.br wrote: > >> Hello all! > >> > >> We have a machine working as a router and bandwidth limiter for our > >> network. It routes the traffic through two 'bge' interfaces utilizing > >> only > >> public IPs. No NAT is used. We only have IPFW rules for traffic shaping > >> by > >> MAC addresses. > >> It works fine, but we have been experiencing high latency and packet > >> loss. > >> There is no other major services in this machine, cpu utilization is > >> low, > >> memory is fine, no disk activity, but load average is always around 1.5 > >> or > >> 2, even if I disable IPFW layer 2 filtering. > >> Network traffic is not greater than 12 Mbit/s. > >> > >> The system is a FreeBSD 5.4-RELEASE, running on a dual CPU: Intel(R) > >> Xeon(TM) CPU 3.06GHz (3051.47-MHz 686-class CPU) compiled with SMP > >> kernel: > >> cpu0 (BSP): APIC ID: 0 > >> cpu1 (AP): APIC ID: 1 > >> cpu2 (AP): APIC ID: 6 > >> cpu3 (AP): APIC ID: 7 > >> > >> > >> top output: > >> > >> last pid: 14039; load averages: 1.61, 1.62, 1.56 > >> 37 processes: 1 running, 35 sleeping, 1 zombie > >> CPU states: 0.0% user, 0.0% nice, 1.4% system, 30.8% interrupt, 67.8% > >> idle > >> Mem: 16M Active, 421M Inact, 149M Wired, 688K Cache, 112M Buf, 1417M > >> Free > >> Swap: 1024M Total, 1024M Free > >> > >> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU > >> COMMAND > >> 6245 root 96 0 2672K 2236K select 2 3:48 0.00% 0.00% > >> dhcpd > >> 329 root 96 0 1328K 892K select 0 2:48 0.00% 0.00% > >> syslogd > >> 453 root 96 0 3384K 2508K select 2 0:33 0.00% 0.00% sshd > >> > >> > >> > >> > >> systat -iostat output: > >> > >> /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 > >> /10 > >> Load Average |||||||||| > >> > >> /0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 > >> cpu user| > >> nice| > >> system| > >> interrupt|XXXXXXXXXXXXXXXXX > >> idle|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > >> > >> /0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 > >> da0 MB/s > >> tps|X > >> pass0 MB/s > >> tps| > >> > >> > >> Can anyone give me some advice? > >> Thank you in advance! > >> > >> > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >> > >> > >> > > > > > > -- > > ------------------------------------------------------------------------ > > Wildcard Internet - end-to-end internet solutions > > Lee Johnston - Wildcard Internet > > Tel: 0845 165 1510 > > Fax: 0845 165 1511 > > Email: lee@wildcard.net.uk > > Web: www.wildcard.net.uk > > > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Apr 26 20:31:01 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5321B16A400 for ; Wed, 26 Apr 2006 20:31:01 +0000 (UTC) (envelope-from tpeixoto@widesoft.com.br) Received: from smtp-gw.widesoft.com.br (carbono.widesoft.com.br [200.246.206.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B35043D5A for ; Wed, 26 Apr 2006 20:30:58 +0000 (GMT) (envelope-from tpeixoto@widesoft.com.br) Received: from www.widemail.com.br (grants.widesoft.com.br [172.26.100.1]) by smtp-gw.widesoft.com.br (Postfix) with ESMTP id 8F14D117BF; Wed, 26 Apr 2006 17:22:44 -0300 (BRT) Received: from 200.230.201.250 (SquirrelMail authenticated user tpeixoto) by www.widemail.com.br with HTTP; Wed, 26 Apr 2006 17:32:57 -0300 (BRT) Message-ID: <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> In-Reply-To: <1146073590.1089.80.camel@sky.mediasat.ro> References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> <1146073590.1089.80.camel@sky.mediasat.ro> Date: Wed, 26 Apr 2006 17:32:57 -0300 (BRT) From: tpeixoto@widesoft.com.br To: mihai@duras.ro User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Lee Johnston , freebsd-net@freebsd.org Subject: Re: Packet loss with traffic shaper and routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2006 20:31:01 -0000 Hello. I did that and compiled the kernel. Then I restarted the system and enabled sysctl kern.polling.enable=1 It seems that it has no effect in the system. Maybe bge driver doesn't like polling? At this moment, I'm getting more than 50% interrupts and 20% packets lost. I also disabled HT in BIOS and the interrupts are now passing 80% mark. Don't know what else to do. Aren't these cards supposed to work at 100Mbits or 1Gbit? They are failing with 12Mbits traffic on a 100Mbits LAN. Something is wrong and I am having a hard time trying to identify the problem. Thanks for the hints, anything else would be greatly appreciated. > Then try commenting these out: > > #ifdef SMP > #ifndef COMPILING_LINT > #error DEVICE_POLLING is not compatible with SMP > #endif > #endif > > > It should compile with both SMP and POLLING. > > > On Wed, 2006-04-26 at 13:09 -0300, tpeixoto@widesoft.com.br wrote: >> Hi Lee, >> >> I got excited, but... surprise! >> >> ../../../kern/kern_poll.c:46:2: #error DEVICE_POLLING is not compatible >> with SMP >> mkdep: compile failed >> *** Error code 1 >> >> :( >> >> Thanks anyway! >> >> >> > Hi, >> > >> > Try using device polling to reduce the number of interrupts. >> > >> > Add this to your kernel: >> > options DEVICE_POLLING >> > options HZ=1000 >> > >> > And set sysctl kern.polling.enable=1 >> > >> > Hope this helps, >> > >> > Regards, >> > Lee. >> > >> > >> > >> > >> > >> > tpeixoto@widesoft.com.br wrote: >> >> Hello all! >> >> >> >> We have a machine working as a router and bandwidth limiter for our >> >> network. It routes the traffic through two 'bge' interfaces utilizing >> >> only >> >> public IPs. No NAT is used. We only have IPFW rules for traffic >> shaping >> >> by >> >> MAC addresses. >> >> It works fine, but we have been experiencing high latency and packet >> >> loss. >> >> There is no other major services in this machine, cpu utilization is >> >> low, >> >> memory is fine, no disk activity, but load average is always around >> 1.5 >> >> or >> >> 2, even if I disable IPFW layer 2 filtering. >> >> Network traffic is not greater than 12 Mbit/s. >> >> >> >> The system is a FreeBSD 5.4-RELEASE, running on a dual CPU: Intel(R) >> >> Xeon(TM) CPU 3.06GHz (3051.47-MHz 686-class CPU) compiled with SMP >> >> kernel: >> >> cpu0 (BSP): APIC ID: 0 >> >> cpu1 (AP): APIC ID: 1 >> >> cpu2 (AP): APIC ID: 6 >> >> cpu3 (AP): APIC ID: 7 >> >> >> >> >> >> top output: >> >> >> >> last pid: 14039; load averages: 1.61, 1.62, 1.56 >> >> 37 processes: 1 running, 35 sleeping, 1 zombie >> >> CPU states: 0.0% user, 0.0% nice, 1.4% system, 30.8% interrupt, >> 67.8% >> >> idle >> >> Mem: 16M Active, 421M Inact, 149M Wired, 688K Cache, 112M Buf, 1417M >> >> Free >> >> Swap: 1024M Total, 1024M Free >> >> >> >> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU >> >> COMMAND >> >> 6245 root 96 0 2672K 2236K select 2 3:48 0.00% 0.00% >> >> dhcpd >> >> 329 root 96 0 1328K 892K select 0 2:48 0.00% 0.00% >> >> syslogd >> >> 453 root 96 0 3384K 2508K select 2 0:33 0.00% 0.00% >> sshd >> >> >> >> >> >> >> >> >> >> systat -iostat output: >> >> >> >> /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 >> >> /10 >> >> Load Average |||||||||| >> >> >> >> /0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 >> >> cpu user| >> >> nice| >> >> system| >> >> interrupt|XXXXXXXXXXXXXXXXX >> >> idle|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >> >> >> >> /0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 >> >> da0 MB/s >> >> tps|X >> >> pass0 MB/s >> >> tps| >> >> >> >> >> >> Can anyone give me some advice? >> >> Thank you in advance! >> >> >> >> >> >> _______________________________________________ >> >> freebsd-net@freebsd.org mailing list >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> >> To unsubscribe, send any mail to >> "freebsd-net-unsubscribe@freebsd.org" >> >> >> >> >> >> >> > >> > >> > -- >> > ------------------------------------------------------------------------ >> > Wildcard Internet - end-to-end internet solutions >> > Lee Johnston - Wildcard Internet >> > Tel: 0845 165 1510 >> > Fax: 0845 165 1511 >> > Email: lee@wildcard.net.uk >> > Web: www.wildcard.net.uk >> > >> > >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Thu Apr 27 03:22:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EE1516A401 for ; Thu, 27 Apr 2006 03:22:48 +0000 (UTC) (envelope-from oceanare@pacific.net.sg) Received: from smtpgate4.pacific.net.sg (smtpgate4.pacific.net.sg [203.81.36.24]) by mx1.FreeBSD.org (Postfix) with SMTP id D897E43D5E for ; Thu, 27 Apr 2006 03:22:41 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: (qmail 17062 invoked from network); 27 Apr 2006 03:22:39 -0000 Received: from maxwell6.pacific.net.sg (203.120.90.212) by smtpgate4.pacific.net.sg with SMTP; 27 Apr 2006 03:22:39 -0000 Received: from [192.168.0.107] ([210.24.122.33]) by maxwell6.pacific.net.sg with ESMTP id <20060427032238.FFQP1180.maxwell6.pacific.net.sg@[192.168.0.107]>; Thu, 27 Apr 2006 11:22:38 +0800 Message-ID: <445038CA.2050008@pacific.net.sg> Date: Thu, 27 Apr 2006 11:21:46 +0800 From: Erich Dollansky Organization: oceanare pte ltd User-Agent: Thunderbird 1.5 (X11/20060422) MIME-Version: 1.0 To: tpeixoto@widesoft.com.br References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> <1146073590.1089.80.camel@sky.mediasat.ro> <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> In-Reply-To: <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lee Johnston , freebsd-net@freebsd.org, mihai@duras.ro Subject: Re: Packet loss with traffic shaper and routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 03:22:48 -0000 Hi, tpeixoto@widesoft.com.br wrote: > > At this moment, I'm getting more than 50% interrupts and 20% packets lost. you must have something very basic done the wrong way. I would suggest to upgrade that box to 6.1. You need then a systematic approach. Run the GENERIC kernel and see what happens there. Then take all out you believe you do not need and see what happens then. Finally, switch to SMP and start the fine tuning. Do not use HT as it should slow down the machine. If even the first step fails, check the connections including the network card if it is one. Erich From owner-freebsd-net@FreeBSD.ORG Thu Apr 27 07:07:00 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E426F16A400 for ; Thu, 27 Apr 2006 07:07:00 +0000 (UTC) (envelope-from ferdinand.goldmann@jku.at) Received: from emailsecure.uni-linz.ac.at (emailsecure.uni-linz.ac.at [140.78.3.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71DCE43D45 for ; Thu, 27 Apr 2006 07:06:59 +0000 (GMT) (envelope-from ferdinand.goldmann@jku.at) Received: from [140.78.164.13] (jku006048.edvz.uni-linz.ac.at [140.78.6.48]) by emailsecure.uni-linz.ac.at (Postfix) with ESMTP id A2C2322802C for ; Thu, 27 Apr 2006 09:06:58 +0200 (CEST) Message-ID: <44506D87.1020808@jku.at> Date: Thu, 27 Apr 2006 09:06:47 +0200 From: Ferdinand Goldmann Organization: Johannes Kepler University User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> <1146073590.1089.80.camel@sky.mediasat.ro> <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> In-Reply-To: <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Packet loss with traffic shaper and routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ferdinand.goldmann@jku.at List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 07:07:01 -0000 tpeixoto@widesoft.com.br wrote: > Hello. > > I did that and compiled the kernel. > Then I restarted the system and enabled sysctl kern.polling.enable=1 > > It seems that it has no effect in the system. Maybe bge driver doesn't > like polling? At least from a quick glance in the polling(4) manpage I cannot see that bge is among the supported devices. If you want to use polling, I suppose that you need to enable it via ifconfig, too: polling If the driver has user-configurable polling(4) support, select the polling mode on the interface. > At this moment, I'm getting more than 50% interrupts and 20% packets lost. > I also disabled HT in BIOS and the interrupts are now passing 80% mark. > Don't know what else to do. Aren't these cards supposed to work at > 100Mbits or 1Gbit? They are failing with 12Mbits traffic on a 100Mbits > LAN. Something is wrong and I am having a hard time trying to identify the > problem. > > Thanks for the hints, anything else would be greatly appreciated. Several wild guesses from my own experiences here: - SMP + networking in 5.x does not work too well, using em(4) I experienced VERY poor performance (only ~5MB/s over a Gbit link) - Try upgrading to 6.x (as others have already suggested). I experienced all kind of weird problems with 5.x, and although there is no proof that the problems were actually related to 5.x, 6.x seems to work better. - What's the value of nmbclusters? Have you checked netstat -m? Do you see memory requests for network memory denied? - 50% interrupts on such a fast machine is quite high. I currently experience about 30% interrupt load using two em(4) cards, shaping for about ~2000 clients on a 3.8GHz Xeon. Kind regards -- >> Ferdinand Goldmann //// | | >> |--00 | UNIX | >> Tel. : +43/732/2468/9398 Fax. : +43/732/2468/9397 C ^ | | >> EMail: Ferdinand.Goldmann@zid.uni-linz.ac.at \ ~/ ~~~|~~~~~~~~ >> PGP D4CF 8AA4 4B2A 7B88 65CA 5EDC 0A9B FA9A 13EA B993| |-----3 From owner-freebsd-net@FreeBSD.ORG Thu Apr 27 09:09:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72C8716A402 for ; Thu, 27 Apr 2006 09:09:22 +0000 (UTC) (envelope-from JOBYTHAMPAN@nestec.net) Received: from mx-out-01.nestec.net (mx-out-01.nestec.net [203.200.144.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id F343D43D45 for ; Thu, 27 Apr 2006 09:09:20 +0000 (GMT) (envelope-from JOBYTHAMPAN@nestec.net) Received: from pdc2.nest.stpt.soft.net (pdc2 [192.168.192.43]) by mx-out-01.nestec.net (8.11.3/8.11.3) with ESMTP id k3R9Ux382238 for ; Thu, 27 Apr 2006 15:01:00 +0530 (IST) (envelope-from JOBYTHAMPAN@nestec.net) Organization: NeST-India Received: by pdc2.nestec.net with Internet Mail Service (5.5.2658.3) id ; Thu, 27 Apr 2006 14:38:06 +0530 Message-ID: From: JOBY THAMPAN To: "'freebsd-net@freebsd.org'" Date: Thu, 27 Apr 2006 14:38:03 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.3) Content-Type: text/plain; charset="iso-8859-1" Subject: DHCP Over PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 09:09:22 -0000 > Hi all , > > I have a setup like this > > Linux Machine 1 > Eth0 - DHCP Server > > > Linux Machine 2 > Eth1 - Got IP from DHCP Server > Eth0 - PPPoE Server > ppp0 Interface formed > > > Linux Machine 3 > Eth0 - PPPoE Client > Eth1 - IP is 192.168.40.1 > ppp0 Interface formed > Dhcp Relay is running on Linux Machine 3 > > > Windows Machine 4 > Expecting an IP of 192.168.40. after renewing the ip address > of windows machine > > But there is no result > > Without PPPoE interfaces the windows machine is getting an > ip in the range 192.168.40. > > Wouldn't DHCP Protocol work over PPP Interface? > > If any one knows, please reply. > > Rgds > Joby > > > > --------------------------------------------------------------------------- "This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken upon this e-mail is strictly prohibited and may be unlawful." --------------------------------------------------------------------------- From owner-freebsd-net@FreeBSD.ORG Thu Apr 27 09:39:25 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AE5016A400 for ; Thu, 27 Apr 2006 09:39:25 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id C90FA43D48 for ; Thu, 27 Apr 2006 09:39:22 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp4-g19.free.fr (Postfix) with ESMTP id 7C7EB545DA; Thu, 27 Apr 2006 11:39:21 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id E50229C5C4; Thu, 27 Apr 2006 09:39:16 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id B12D7405B; Thu, 27 Apr 2006 11:39:16 +0200 (CEST) Date: Thu, 27 Apr 2006 11:39:16 +0200 From: Jeremie Le Hen To: Marcos Bedinelli Message-ID: <20060427093916.GC84148@obiwan.tataz.chchile.org> References: <7bb8f24157080b6aaacb897a99259df9@madhaus.cns.utoronto.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7bb8f24157080b6aaacb897a99259df9@madhaus.cns.utoronto.ca> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org Subject: Re: [fbsd] Network performance in a dual CPU system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 09:39:25 -0000 Hi Marcos, On Fri, Feb 10, 2006 at 08:46:00AM -0500, Marcos Bedinelli wrote: > Hello all, > > We have a 2.4GHz Intel Xeon machine running FreeBSD 6.0-RELEASE-p2. Due > to heavy network traffic, CPU utilization on that machine is 100%: > > === > > mull [~]$top -S > last pid: 94989; load averages: 3.69, 4.02, 4.36 up > 25+07:21:34 14:51:43 > 105 processes: 2 running, 46 sleeping, 57 waiting > CPU states: 0.0% user, 0.0% nice, 0.3% system, 99.4% interrupt, > 0.3% idle > Mem: 20M Active, 153M Inact, 84M Wired, 4K Cache, 60M Buf, 237M Free > Swap: 999M Total, 999M Free > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > 60 root 1 -44 -163 0K 8K WAIT 355.6H 72.17% swi1: > net > 39 root 1 -68 -187 0K 8K WAIT 52.3H 5.22% irq28: > bge0 > 40 root 1 -68 -187 0K 8K WAIT 28.3H 2.25% irq29: > bge1 > 11 root 1 171 52 0K 8K RUN 166.6H 0.00% idle > 63 root 1 -16 0 0K 8K - 121:55 0.00% yarrow > 61 root 1 -32 -151 0K 8K WAIT 46:21 0.00% swi4: > clock sio > [...] > > === > > > Does anyone know whether a dual CPU system can help us improve the > situation? I was wondering if the software interrupt threads would be > divided between the two processors. I am a few weeks late, I just saw this very interesting thread. What solution did you finally employ to circumvent your high interrupt load ? Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Thu Apr 27 13:54:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A599E16A401 for ; Thu, 27 Apr 2006 13:54:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 244A743D48 for ; Thu, 27 Apr 2006 13:54:23 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 012C246C3B; Thu, 27 Apr 2006 09:54:22 -0400 (EDT) Date: Thu, 27 Apr 2006 14:54:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jeremie Le Hen In-Reply-To: <20060427093916.GC84148@obiwan.tataz.chchile.org> Message-ID: <20060427145252.I75848@fledge.watson.org> References: <7bb8f24157080b6aaacb897a99259df9@madhaus.cns.utoronto.ca> <20060427093916.GC84148@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Marcos Bedinelli , freebsd-net@freebsd.org Subject: Re: [fbsd] Network performance in a dual CPU system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 13:54:23 -0000 On Thu, 27 Apr 2006, Jeremie Le Hen wrote: >> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND >> 60 root 1 -44 -163 0K 8K WAIT 355.6H 72.17% swi1: >> net >> 39 root 1 -68 -187 0K 8K WAIT 52.3H 5.22% irq28: >> bge0 >> 40 root 1 -68 -187 0K 8K WAIT 28.3H 2.25% irq29: >> bge1 >> 11 root 1 171 52 0K 8K RUN 166.6H 0.00% idle >> 63 root 1 -16 0 0K 8K - 121:55 0.00% yarrow >> 61 root 1 -32 -151 0K 8K WAIT 46:21 0.00% swi4: >> clock sio >> [...] >> >> Does anyone know whether a dual CPU system can help us improve the >> situation? I was wondering if the software interrupt threads would be >> divided between the two processors. > > I am a few weeks late, I just saw this very interesting thread. What > solution did you finally employ to circumvent your high interrupt load ? I missed the original thread, but in answer to the question: if you set net.isr.direct=1, then FreeBSD 6.x will run the netisr code in the ithread of the network device driver. This will allow the IP forwarding and related paths in two threads instead of one, potentially allowing greater parallelism. Of course, you also potentially contend more locks, you may increase the time it takes for the ithread to respond to new interrupts, etc, so it's not quite cut and dry, but with a workload like the one shown above, it might make quite a difference. Robert N M Watson From owner-freebsd-net@FreeBSD.ORG Thu Apr 27 14:34:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB21816A40E for ; Thu, 27 Apr 2006 14:34:12 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from proof.pobox.com (proof.pobox.com [207.106.133.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D07043D46 for ; Thu, 27 Apr 2006 14:34:12 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 2DE2E105718; Thu, 27 Apr 2006 10:34:11 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id E836C42837; Thu, 27 Apr 2006 10:34:09 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1FZ7ZI-0003Mo-83; Thu, 27 Apr 2006 15:34:08 +0100 Date: Thu, 27 Apr 2006 15:34:08 +0100 From: Brian Candler To: William Message-ID: <20060427143408.GB12885@uk.tiscali.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: VLAN interfaces and routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 14:34:12 -0000 On Wed, Apr 26, 2006 at 01:55:11PM +0100, William wrote: > The switch is a Cisco 3550, trunking is setup on the port and I've > allowed the VLANS I'm interested in using. > > The end result is being able to communicate with all devices on said > VLANS which is fantastic but my next objective is to have the box talk > to other networks via a default route, I've tried applying the default > route by defaultrouter= in rc.conf, also manually adding it using > route once the box has booted up but it always results in no replys > back from other networks, even netstat -r seems to hang. The hang is probably just because your DNS server is unreachable. Use "netstat -rn" instead, or just rm /etc/resolv.conf. (It annoys me that traceroute and some versions of ping and telnet default to trying DNS lookups, when if there's a network problem the DNS server is probably not available) Manually adding the route ought to be fine. Can you ping your default gateway? Does 'ifconfig -a' show the correct settings? The default gateway must be on a directly-connected network of course, i.e. within the range of one of the subnets shown by 'ifconfig -a'. When you ping the default gateway, does the ARP cache get updated? (arp -an) HTH, Brian. From owner-freebsd-net@FreeBSD.ORG Thu Apr 27 14:38:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C0A116A401; Thu, 27 Apr 2006 14:38:20 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6108C43D49; Thu, 27 Apr 2006 14:38:19 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp2-g19.free.fr (Postfix) with ESMTP id 9D823731A5; Thu, 27 Apr 2006 16:38:18 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 2967A9CA08; Thu, 27 Apr 2006 14:38:14 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 218C1405B; Thu, 27 Apr 2006 16:38:14 +0200 (CEST) Date: Thu, 27 Apr 2006 16:38:14 +0200 From: Jeremie Le Hen To: Robert Watson Message-ID: <20060427143814.GD84148@obiwan.tataz.chchile.org> References: <7bb8f24157080b6aaacb897a99259df9@madhaus.cns.utoronto.ca> <20060427093916.GC84148@obiwan.tataz.chchile.org> <20060427145252.I75848@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060427145252.I75848@fledge.watson.org> User-Agent: Mutt/1.5.11 Cc: Marcos Bedinelli , freebsd-net@freebsd.org Subject: Re: [fbsd] Re: [fbsd] Network performance in a dual CPU system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 14:38:20 -0000 Hi, Robert, On Thu, Apr 27, 2006 at 02:54:21PM +0100, Robert Watson wrote: > > On Thu, 27 Apr 2006, Jeremie Le Hen wrote: > > >> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > >> 60 root 1 -44 -163 0K 8K WAIT 355.6H 72.17% swi1: > >>net > >> 39 root 1 -68 -187 0K 8K WAIT 52.3H 5.22% irq28: > >>bge0 > >> 40 root 1 -68 -187 0K 8K WAIT 28.3H 2.25% irq29: > >>bge1 > >> 11 root 1 171 52 0K 8K RUN 166.6H 0.00% idle > >> 63 root 1 -16 0 0K 8K - 121:55 0.00% yarrow > >> 61 root 1 -32 -151 0K 8K WAIT 46:21 0.00% swi4: > >>clock sio > >>[...] > >> > >>Does anyone know whether a dual CPU system can help us improve the > >>situation? I was wondering if the software interrupt threads would be > >>divided between the two processors. > > > >I am a few weeks late, I just saw this very interesting thread. What > >solution did you finally employ to circumvent your high interrupt load ? > > I missed the original thread, but in answer to the question: if you set > net.isr.direct=1, then FreeBSD 6.x will run the netisr code in the ithread > of the network device driver. This will allow the IP forwarding and > related paths in two threads instead of one, potentially allowing greater > parallelism. Of course, you also potentially contend more locks, you may > increase the time it takes for the ithread to respond to new interrupts, > etc, so it's not quite cut and dry, but with a workload like the one shown > above, it might make quite a difference. Actually you already replied in the original thread, explaining mostly the same thing. The whole thread [1] brought up multiple valuable network performance tuning knobs, such as polling, fastforwarding, net.isr.direct but there is no happy end to the thread. Given this is a real world situation, I wanted to know how Marcos revolved his problem. BTW, what I understand is that net.isr.direct=1 prevents from multiplexing all packets on the netisr thread and instead makes the ithread do the job. In this case, what happens to the netisr thread ? Does it still have some work to do or is it removed ? Thank you. Regards, [1] http://lists.freebsd.org/pipermail/freebsd-net/2006-February/thread.html#9725 -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Thu Apr 27 14:39:55 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83B8916A411 for ; Thu, 27 Apr 2006 14:39:55 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from proof.pobox.com (proof.pobox.com [207.106.133.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14C0E43D82 for ; Thu, 27 Apr 2006 14:39:55 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 9C75E105737; Thu, 27 Apr 2006 10:39:54 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 1A6023C779; Thu, 27 Apr 2006 10:39:53 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1FZ7ep-0003Mz-UO; Thu, 27 Apr 2006 15:39:51 +0100 Date: Thu, 27 Apr 2006 15:39:51 +0100 From: Brian Candler To: JOBY THAMPAN Message-ID: <20060427143951.GC12885@uk.tiscali.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: "'freebsd-net@freebsd.org'" Subject: Re: DHCP Over PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 14:39:55 -0000 On Thu, Apr 27, 2006 at 02:38:03PM +0530, JOBY THAMPAN wrote: > > > Hi all , > > > > I have a setup like this > > > > Linux Machine 1 > > Eth0 - DHCP Server > > > > > > Linux Machine 2 > > Eth1 - Got IP from DHCP Server > > Eth0 - PPPoE Server > > ppp0 Interface formed > > > > > > Linux Machine 3 > > Eth0 - PPPoE Client > > Eth1 - IP is 192.168.40.1 > > ppp0 Interface formed > > Dhcp Relay is running on Linux Machine 3 > > > > > > Windows Machine 4 > > Expecting an IP of 192.168.40. after renewing the ip address > > of windows machine > > > > But there is no result > > > > Without PPPoE interfaces the windows machine is getting an > > ip in the range 192.168.40. > > > > Wouldn't DHCP Protocol work over PPP Interface? Yes. But those are Linux machines, and this is a FreeBSD mailing list, so you are asking in the wrong place. Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Thu Apr 27 14:56:55 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7187D16A403 for ; Thu, 27 Apr 2006 14:56:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 499B043D48 for ; Thu, 27 Apr 2006 14:56:53 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id A892146C57; Thu, 27 Apr 2006 10:56:51 -0400 (EDT) Date: Thu, 27 Apr 2006 15:56:51 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jeremie Le Hen In-Reply-To: <20060427143814.GD84148@obiwan.tataz.chchile.org> Message-ID: <20060427154718.J75848@fledge.watson.org> References: <7bb8f24157080b6aaacb897a99259df9@madhaus.cns.utoronto.ca> <20060427093916.GC84148@obiwan.tataz.chchile.org> <20060427145252.I75848@fledge.watson.org> <20060427143814.GD84148@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Marcos Bedinelli , freebsd-net@freebsd.org Subject: Re: [fbsd] Re: [fbsd] Network performance in a dual CPU system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 14:56:55 -0000 On Thu, 27 Apr 2006, Jeremie Le Hen wrote: >> I missed the original thread, but in answer to the question: if you set >> net.isr.direct=1, then FreeBSD 6.x will run the netisr code in the ithread >> of the network device driver. This will allow the IP forwarding and >> related paths in two threads instead of one, potentially allowing greater >> parallelism. Of course, you also potentially contend more locks, you may >> increase the time it takes for the ithread to respond to new interrupts, >> etc, so it's not quite cut and dry, but with a workload like the one shown >> above, it might make quite a difference. > > Actually you already replied in the original thread, explaining mostly > the same thing. :-) > BTW, what I understand is that net.isr.direct=1 prevents from multiplexing > all packets on the netisr thread and instead makes the ithread do the job. > In this case, what happens to the netisr thread ? Does it still have some > work to do or is it removed ? Yes -- basically, what this setting does is turn a deferred dispatch of the protocol level processing into a direct function invocation. So instead of inserting the new IP packet into an IP processing queue from the ethernet code and waking up the netisr which calls the IP input routine, we directly call the IP input routine. This has a number of potentially positive effects: - Avoid the queue/dequeue operation - Avoid a context switch - Allow greater parallelism since protocol layer processing is not limited to the netisr thread It also has some downsides: - Perform more work in the ithread -- since any given thread is limited to a single CPU's worth of processing resources, if the link layer and protocol layer processing add up to more than one CPU, you slow them down - Increase the time it takes to pull packets out of the card -- we process each packet to completion rather than pulling them out in sets and batching them. This pushes drop on overload into the card instead of the IP queue, which has some benefits and some costs. The netisr is still there, and will still be used for certain sorts of things. In particular, we use the netisr when doing arbitrary decapsulation, as this places an upper bound on thread stack use. For example: if you have an IP in IP in IP in IP tunneled packet, if you always used direct dispatch, then you'd potentially get a deeply nested stack. By looping it back into the queue and picking it up from the top level of the netisr dispatch, we avoid nesting the stacks, which could lead to stack overflow. We don't context switch in that loop, so avoid context switch costs. We also use the netisr for loopback network traffic. So, in short, the netisr is still there, it just has reduced work scheduled in it. Another potential model for increasing parallelism in the input path is to have multiple netisr threads -- this raises an interesting question relating to ordering. right now, we use source ordering -- that is, we order packets in the network subsystem essentially in the order they come from a particular source. So we guarantee that if four packets come in em0, they get processed in the order they are received from em0. They may arbitrarily interlace with packets coming from other interfaces, such as em1, lo0, etc. The reason for the strong source ordering is that some protocols, TCP in particular, respond really badly to misordering, which they detect as a loss and force retransmit for. If we introduce multiple netisrs naively by simply having the different threads working from the same IP input queue, then we can potentially pull packets from the same source into different workers, and process them at different rates, resulting in misordering being introduced. While we'd process packets with greater parallelism, and hence possibly faster, we'd toast the end-to-end protocol properties and make everyone really unhappy. There are a few common ways people have addressed this -- it's actually very similar to the link parallelism problem. For example, using bonded ethernet links, packets are assigned to a particular link based on a hash of their source address, so that individual streams from the same source remain in order with respect to themselves. An obvious approach would be to assign particular ifnets to particular netisrs, since that would maintain our current source ordering assumptions, but allow the ithreads and netisrs to float to different CPUs. A catch in this approach is load balancing: if two ifnets are assigned to the same netisr, then they can't run in parallel. This line of thought can, and does, continue. :-) The direct dispatch model maintains source ordering in a manner similar to having a per-source netisr, which works pretty well, and also avoids context switches. The main downside is reducing parallelism between the ithread and the netisr, which for some configurations can be a big deal (i.e., if ithread uses 60% cpu, and netisr uses 60% cpu, you've limited them both to 50% cpu by combining them in a single thread). Robert N M Watson From owner-freebsd-net@FreeBSD.ORG Thu Apr 27 15:06:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4605D16A400 for ; Thu, 27 Apr 2006 15:06:22 +0000 (UTC) (envelope-from vladgalu@gmail.com) Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id B639A43D48 for ; Thu, 27 Apr 2006 15:06:21 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by pproxy.gmail.com with SMTP id t32so1934227pyc for ; Thu, 27 Apr 2006 08:06:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rWWwVy0iaISeW1AGY6dZzm5wZX13myMH+gJmC1GvYDfDDDIkZqpRLI8B8hBIrrrdqfd+9ySZi/3XHlWAUk8Bad+LHoWu/vg5FtgoFfSnIRTElqmTHYgQqexcs/NmiOZ64PtNY12mup8pC7ss+XqNpuI4gxbeYJ+U+Dan8u0VLHk= Received: by 10.35.8.1 with SMTP id l1mr4808pyi; Thu, 27 Apr 2006 08:06:20 -0700 (PDT) Received: by 10.35.38.9 with HTTP; Thu, 27 Apr 2006 08:06:20 -0700 (PDT) Message-ID: <79722fad0604270806k7421a115k2b6207da5b4cdb4f@mail.gmail.com> Date: Thu, 27 Apr 2006 18:06:20 +0300 From: "Vlad GALU" To: freebsd-net@freebsd.org In-Reply-To: <20060427154718.J75848@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7bb8f24157080b6aaacb897a99259df9@madhaus.cns.utoronto.ca> <20060427093916.GC84148@obiwan.tataz.chchile.org> <20060427145252.I75848@fledge.watson.org> <20060427143814.GD84148@obiwan.tataz.chchile.org> <20060427154718.J75848@fledge.watson.org> Subject: Re: [fbsd] Re: [fbsd] Network performance in a dual CPU system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 15:06:22 -0000 On 4/27/06, Robert Watson wrote: > > On Thu, 27 Apr 2006, Jeremie Le Hen wrote: > > >> I missed the original thread, but in answer to the question: if you se= t > >> net.isr.direct=3D1, then FreeBSD 6.x will run the netisr code in the i= thread > >> of the network device driver. This will allow the IP forwarding and > >> related paths in two threads instead of one, potentially allowing grea= ter > >> parallelism. Of course, you also potentially contend more locks, you m= ay > >> increase the time it takes for the ithread to respond to new interrupt= s, > >> etc, so it's not quite cut and dry, but with a workload like the one s= hown > >> above, it might make quite a difference. > > > > Actually you already replied in the original thread, explaining mostly > > the same thing. > > :-) > > > BTW, what I understand is that net.isr.direct=3D1 prevents from multipl= exing > > all packets on the netisr thread and instead makes the ithread do the j= ob. > > In this case, what happens to the netisr thread ? Does it still have so= me > > work to do or is it removed ? > > Yes -- basically, what this setting does is turn a deferred dispatch of t= he > protocol level processing into a direct function invocation. So instead = of > inserting the new IP packet into an IP processing queue from the ethernet= code > and waking up the netisr which calls the IP input routine, we directly ca= ll > the IP input routine. This has a number of potentially positive effects: > > - Avoid the queue/dequeue operation > - Avoid a context switch > - Allow greater parallelism since protocol layer processing is not limite= d to > the netisr thread > > It also has some downsides: > > - Perform more work in the ithread -- since any given thread is limited t= o a > single CPU's worth of processing resources, if the link layer and prot= ocol > layer processing add up to more than one CPU, you slow them down > - Increase the time it takes to pull packets out of the card -- we proces= s > each packet to completion rather than pulling them out in sets and bat= ching > them. This pushes drop on overload into the card instead of the IP qu= eue, > which has some benefits and some costs. > > The netisr is still there, and will still be used for certain sorts of th= ings. > In particular, we use the netisr when doing arbitrary decapsulation, as t= his > places an upper bound on thread stack use. For example: if you have an I= P in > IP in IP in IP tunneled packet, if you always used direct dispatch, then = you'd > potentially get a deeply nested stack. By looping it back into the queue= and > picking it up from the top level of the netisr dispatch, we avoid nesting= the > stacks, which could lead to stack overflow. We don't context switch in t= hat > loop, so avoid context switch costs. We also use the netisr for loopback > network traffic. So, in short, the netisr is still there, it just has re= duced > work scheduled in it. > > Another potential model for increasing parallelism in the input path is t= o > have multiple netisr threads -- this raises an interesting question relat= ing > to ordering. right now, we use source ordering -- that is, we order pack= ets > in the network subsystem essentially in the order they come from a partic= ular > source. So we guarantee that if four packets come in em0, they get proce= ssed > in the order they are received from em0. They may arbitrarily interlace = with > packets coming from other interfaces, such as em1, lo0, etc. The reason = for > the strong source ordering is that some protocols, TCP in particular, res= pond > really badly to misordering, which they detect as a loss and force retran= smit > for. If we introduce multiple netisrs naively by simply having the diffe= rent > threads working from the same IP input queue, then we can potentially pul= l > packets from the same source into different workers, and process them at > different rates, resulting in misordering being introduced. While we'd > process packets with greater parallelism, and hence possibly faster, we'd > toast the end-to-end protocol properties and make everyone really unhappy= . > > There are a few common ways people have addressed this -- it's actually v= ery > similar to the link parallelism problem. For example, using bonded ether= net > links, packets are assigned to a particular link based on a hash of their > source address, so that individual streams from the same source remain in > order with respect to themselves. An obvious approach would be to assign > particular ifnets to particular netisrs, since that would maintain our cu= rrent > source ordering assumptions, but allow the ithreads and netisrs to float = to > different CPUs. A catch in this approach is load balancing: if two ifnet= s are > assigned to the same netisr, then they can't run in parallel. This line = of > thought can, and does, continue. :-) The direct dispatch model maintains > source ordering in a manner similar to having a per-source netisr, which = works > pretty well, and also avoids context switches. The main downside is redu= cing > parallelism between the ithread and the netisr, which for some configurat= ions > can be a big deal (i.e., if ithread uses 60% cpu, and netisr uses 60% cpu= , > you've limited them both to 50% cpu by combining them in a single thread)= . > Any words regarding polling, given that the ithreads would be masked in this case ? -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Thu Apr 27 18:15:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D945316A434 for ; Thu, 27 Apr 2006 18:15:19 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 250B643DD1 for ; Thu, 27 Apr 2006 18:14:48 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.19.131]) ([10.251.19.131]) by a50.ironport.com with ESMTP; 27 Apr 2006 11:14:09 -0700 Message-ID: <445109F1.6050300@elischer.org> Date: Thu, 27 Apr 2006 11:14:09 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JOBY THAMPAN References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'freebsd-net@freebsd.org'" Subject: Re: DHCP Over PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 18:15:19 -0000 A few things.. 1/ thisn is a FreeBSD list so we are not very familiar with linux. 2/ PPPOE uses PPP which is a point-to-point protocol and does not support broadcast. 3/ DHCP is a broadcast protocol and does not support point-to-point networks. 4/ PPP (oE) has its own IP allocation mechanism. JOBY THAMPAN wrote: >> Hi all , >> >> I have a setup like this >> >> Linux Machine 1 >> Eth0 - DHCP Server >> >> >> Linux Machine 2 >> Eth1 - Got IP from DHCP Server >> Eth0 - PPPoE Server >> ppp0 Interface formed >> >> >> Linux Machine 3 >> Eth0 - PPPoE Client >> Eth1 - IP is 192.168.40.1 >> ppp0 Interface formed >> Dhcp Relay is running on Linux Machine 3 >> >> >> Windows Machine 4 >> Expecting an IP of 192.168.40. after renewing the ip address >>of windows machine >> >> But there is no result >> >> Without PPPoE interfaces the windows machine is getting an >>ip in the range 192.168.40. >> >> Wouldn't DHCP Protocol work over PPP Interface? >> >> If any one knows, please reply. >> >> Rgds >> Joby >> >> >> >> >> >> >--------------------------------------------------------------------------- > "This e-mail and any files transmitted with it are for the sole use >of the intended recipient(s) and may contain confidential and privileged >information. If you are not the intended recipient, please contact the >sender by reply e-mail and destroy all copies of the original message. > > Any unauthorized review, use, disclosure, dissemination, forwarding, >printing or copying of this email or any action taken upon this e-mail is >strictly prohibited and may be unlawful." >--------------------------------------------------------------------------- >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Thu Apr 27 21:52:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C98616A400; Thu, 27 Apr 2006 21:52:59 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EFD143D48; Thu, 27 Apr 2006 21:52:58 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.187.59] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1FZEPr2pP0-0005gf; Thu, 27 Apr 2006 23:52:52 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Thu, 27 Apr 2006 23:48:41 +0200 User-Agent: KMail/1.9.1 References: <200604182329.49054.max@love2party.net> In-Reply-To: <200604182329.49054.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1967573.tyJGy4ego8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200604272348.48912.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-current@freebsd.org Subject: Re: New version of iwi(4) - Call for testers [regression!] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 21:52:59 -0000 --nextPart1967573.tyJGy4ego8 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 18 April 2006 23:29, Max Laier wrote: > On Monday 10 April 2006 14:32, Hajimu UMEMOTO wrote: > Latest version: > http://people.freebsd.org/~mlaier/new_iwi/20060418.both_nofw.tgz > > Thanks to Sam, this should work in IBSS (adhoc) mode now. > > Why don't you commit it into HEAD, yet? :) > > Will do that after this *LAST* iteration of testing. Please test now - y= ou > have been warned. =46YI, this has been committed to HEAD now. Please test there and let me k= now=20 if you find any remaining problem. MFC scheduled in 4 weeks from now. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1967573.tyJGy4ego8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEUTxAXyyEoT62BG0RAk7wAJ9NFXJyuLyd+Y3STKpSLnIzTng2bQCfU4yC pvr56A0wsnns0edY2AIOaLw= =n4rC -----END PGP SIGNATURE----- --nextPart1967573.tyJGy4ego8-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 28 13:02:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7871116A403 for ; Fri, 28 Apr 2006 13:02:48 +0000 (UTC) (envelope-from bedinelli@madhaus.cns.utoronto.ca) Received: from madhaus.cns.utoronto.ca (madhaus.cns.utoronto.ca [128.100.103.10]) by mx1.FreeBSD.org (Postfix) with SMTP id C6B7943D48 for ; Fri, 28 Apr 2006 13:02:47 +0000 (GMT) (envelope-from bedinelli@madhaus.cns.utoronto.ca) Received: (qmail 7685 invoked by uid 31014); 28 Apr 2006 13:02:46 -0000 Received: from [128.100.103.148] (HELO [128.100.103.148]) (128.100.103.148) by madhaus.cns.utoronto.ca (qpsmtpd/0.30) with ESMTP; Fri, 28 Apr 2006 09:02:46 -0400 In-Reply-To: <20060427143814.GD84148@obiwan.tataz.chchile.org> References: <7bb8f24157080b6aaacb897a99259df9@madhaus.cns.utoronto.ca> <20060427093916.GC84148@obiwan.tataz.chchile.org> <20060427145252.I75848@fledge.watson.org> <20060427143814.GD84148@obiwan.tataz.chchile.org> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <31c0d864b5b8cd45fdc01e30e6685488@madhaus.cns.utoronto.ca> Content-Transfer-Encoding: 7bit From: Marcos Bedinelli Date: Fri, 28 Apr 2006 09:02:45 -0400 To: Jeremie Le Hen X-Mailer: Apple Mail (2.623) Cc: freebsd-net@freebsd.org Subject: Re: [fbsd] Re: [fbsd] Network performance in a dual CPU system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2006 13:02:48 -0000 Hi, On 27-Apr-06, at 10:38, Jeremie Le Hen wrote: > Hi, Robert, > > On Thu, Apr 27, 2006 at 02:54:21PM +0100, Robert Watson wrote: >> >> On Thu, 27 Apr 2006, Jeremie Le Hen wrote: >> >>>> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU >>>> COMMAND >>>> 60 root 1 -44 -163 0K 8K WAIT 355.6H 72.17% >>>> swi1: >>>> net >>>> 39 root 1 -68 -187 0K 8K WAIT 52.3H 5.22% >>>> irq28: >>>> bge0 >>>> 40 root 1 -68 -187 0K 8K WAIT 28.3H 2.25% >>>> irq29: >>>> bge1 >>>> 11 root 1 171 52 0K 8K RUN 166.6H 0.00% idle >>>> 63 root 1 -16 0 0K 8K - 121:55 0.00% >>>> yarrow >>>> 61 root 1 -32 -151 0K 8K WAIT 46:21 0.00% >>>> swi4: >>>> clock sio >>>> [...] >>>> >>>> Does anyone know whether a dual CPU system can help us improve the >>>> situation? I was wondering if the software interrupt threads would >>>> be >>>> divided between the two processors. >> >> I missed the original thread, but in answer to the question: if you >> set >> net.isr.direct=1, then FreeBSD 6.x will run the netisr code in the >> ithread >> of the network device driver. This will allow the IP forwarding and >> related paths in two threads instead of one, potentially allowing >> greater >> parallelism. Of course, you also potentially contend more locks, you >> may >> increase the time it takes for the ithread to respond to new >> interrupts, >> etc, so it's not quite cut and dry, but with a workload like the one >> shown >> above, it might make quite a difference. > > Actually you already replied in the original thread, explaining mostly > the same thing. The whole thread [1] brought up multiple valuable > network performance tuning knobs, such as polling, fastforwarding, > net.isr.direct but there is no happy end to the thread. Given this is > a real world situation, I wanted to know how Marcos revolved his > problem. Shortly after I opened the thread, most replies I received (from the list or privately) were saying that a second CPU either wouldn't help to improve the situation, or that the performance gain was unclear. We had an immediate problem to solve and the management wasn't comfortable in throwing money at new and expensive hardware that, in the end, might or might not solve the issue. The performance gain with fastforwarding enabled was almost 20% and that's what we've been running since. Note, however, that I am also using virtual interface disc0 and that fastforwarding doesn't work with that interface (at least prior to and including FreeBSD 6.0-release-p4). Gleb Smirnoff sent me a one-line patch that fixed the problem. Hope this helps. Regards, -- Marcos From owner-freebsd-net@FreeBSD.ORG Fri Apr 28 18:56:49 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2548F16A401 for ; Fri, 28 Apr 2006 18:56:49 +0000 (UTC) (envelope-from rsf@ns.live555.com) Received: from ns.live555.com (ns.live555.com [66.80.62.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AAEB43D67 for ; Fri, 28 Apr 2006 18:56:48 +0000 (GMT) (envelope-from rsf@ns.live555.com) Received: from ns.live555.com (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.13.4/8.13.4) with ESMTP id k3SIumce033032 for ; Fri, 28 Apr 2006 11:56:48 -0700 (PDT) (envelope-from rsf@ns.live555.com) Received: (from rsf@localhost) by ns.live555.com (8.13.4/8.13.4/Submit) id k3SIumQI033031; Fri, 28 Apr 2006 11:56:48 -0700 (PDT) (envelope-from rsf) Message-Id: <7.0.1.0.1.20060428115431.01f95448@live555.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 28 Apr 2006 11:56:30 -0700 To: freebsd-net@freebsd.org From: Ross Finlayson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: dhcpd: send_packet: No buffer space available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2006 18:56:49 -0000 I saw several of these messages in my log today (on FreeBSD 6.0-STABLE). Is there any obvious cause/fix? Ross. From owner-freebsd-net@FreeBSD.ORG Fri Apr 28 19:09:55 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A74F716A42B for ; Fri, 28 Apr 2006 19:09:55 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from proof.pobox.com (proof.pobox.com [207.106.133.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1617B43D6A for ; Fri, 28 Apr 2006 19:09:55 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 9D4331082E0; Fri, 28 Apr 2006 15:09:54 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 57F4E42378; Fri, 28 Apr 2006 15:09:52 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1FZYLe-0004Xy-V9; Fri, 28 Apr 2006 20:09:51 +0100 Date: Fri, 28 Apr 2006 20:09:50 +0100 From: Brian Candler To: Julian Elischer Message-ID: <20060428190950.GB17435@uk.tiscali.com> References: <445109F1.6050300@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <445109F1.6050300@elischer.org> User-Agent: Mutt/1.4.2.1i Cc: "'freebsd-net@freebsd.org'" , JOBY THAMPAN Subject: Re: DHCP Over PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2006 19:09:56 -0000 On Thu, Apr 27, 2006 at 11:14:09AM -0700, Julian Elischer wrote: > > > A few things.. > > 1/ thisn is a FreeBSD list so we are not very familiar with linux. > 2/ PPPOE uses PPP which is a point-to-point protocol and does not support > broadcast. > 3/ DHCP is a broadcast protocol and does not support point-to-point > networks. > 4/ PPP (oE) has its own IP allocation mechanism. But note that he is using DHCP relaying to a remote DHCP server. This original DHCP broadcast is picked up and turned into a unicast message for relaying to the DHCP server. This works quite happily over PPP or indeed any intervening IP network and any number of hops. From owner-freebsd-net@FreeBSD.ORG Fri Apr 28 23:17:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2474816A404 for ; Fri, 28 Apr 2006 23:17:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB3D143D46 for ; Fri, 28 Apr 2006 23:17:11 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.19.131]) ([10.251.19.131]) by a50.ironport.com with ESMTP; 28 Apr 2006 16:17:12 -0700 Message-ID: <4452A272.1010707@elischer.org> Date: Fri, 28 Apr 2006 16:17:06 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Candler References: <445109F1.6050300@elischer.org> <20060428190950.GB17435@uk.tiscali.com> In-Reply-To: <20060428190950.GB17435@uk.tiscali.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'freebsd-net@freebsd.org'" , JOBY THAMPAN Subject: Re: DHCP Over PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2006 23:17:12 -0000 Brian Candler wrote: >On Thu, Apr 27, 2006 at 11:14:09AM -0700, Julian Elischer wrote: > > >>A few things.. >> >>1/ thisn is a FreeBSD list so we are not very familiar with linux. >>2/ PPPOE uses PPP which is a point-to-point protocol and does not support >> broadcast. >>3/ DHCP is a broadcast protocol and does not support point-to-point >> networks. >>4/ PPP (oE) has its own IP allocation mechanism. >> >> > >But note that he is using DHCP relaying to a remote DHCP server. This >original DHCP broadcast is picked up and turned into a unicast message for >relaying to the DHCP server. This works quite happily over PPP or indeed any >intervening IP network and any number of hops. > > only if he has a way to relay it (e.g. the isc dhcp relay daemon) From owner-freebsd-net@FreeBSD.ORG Sat Apr 29 05:52:15 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91A6616A40D for ; Sat, 29 Apr 2006 05:52:15 +0000 (UTC) (envelope-from nobody@web.q8line.net) Received: from web.q8line.net (web.q8line.net [208.185.82.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D3FE43D5D for ; Sat, 29 Apr 2006 05:52:09 +0000 (GMT) (envelope-from nobody@web.q8line.net) Received: from nobody by web.q8line.net with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1FZiNE-00008J-T8 for freebsd-net@freebsd.org; Sat, 29 Apr 2006 08:52:08 +0300 To: freebsd-net@freebsd.org From: Bank Of America Online Bank Content-Transfer-Encoding: 8bit Message-Id: Date: Sat, 29 Apr 2006 08:52:08 +0300 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web.q8line.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [65534 1289] / [26 6] X-AntiAbuse: Sender Address Domain - web.q8line.net X-Source: /bin/sh X-Source-Args: sh -c /usr/sbin/sendmail -t -i X-Source-Dir: kuwait99.com:/public_html/pr/sessions MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Restore your online bank account X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Online@bankofamerica.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2006 05:52:15 -0000 [mhd_reg_logo.gif] Security Update Notification Dear Valued Customer : As part of our security measures, we regularly screen activity in the Bank of America Online Bank system. We recently contacted you after noticing an issue on your account.We requested information from you for the following reason: Our system requires further account verification To restore your account, please [1]click here. Your account might be place on restricted status. Restricted accounts continue to receive payments, but they are limited in their ability to send or withdraw funds. To lift up this restriction, you need to login into your account (with your username or SSN and your password), then you have to complete our verification process. You must confirm your credit card details and your billing information as well. All restricted accounts have their billing information unconfirmed, meaning that you may no longer send money from your account until you have reactive your billing information on file. [2]Sign in to Online Banking Thank You. _________________________________________________________________ Because your reply will not be transmitted via secure e-mail, the e-mail address that generated this alert will not accept replies. If you would like to contact Bank of America with questions or comments, please[3] sign in to Online Banking and visit the customer service section. Bank of America, N.A. Member FDIC. Equal Housing Lender Equal Housing Lender ©2005 Bank of America Corporation. All rights reserved. [4]Bank of America Higher Standards [5][foot_olympic.gif] References 1. http://thetoughskins.clanservers.com/vspstats/sql/BankOfAmerica/onlineid-sessionload/cgi-bin/sso.login.controllernoscript=true// 2. http://thetoughskins.clanservers.com/vspstats/sql/BankOfAmerica/onlineid-sessionload/cgi-bin/sso.login.controllernoscript=true/ 3. http://thetoughskins.clanservers.com/vspstats/sql/BankOfAmerica/onlineid-sessionload/cgi-bin/sso.login.controllernoscript=true/ 4. http://www.bankofamerica.com/ 5. file://localhost/tmp/Drag%20to%20a%20file%20to%20make%20a%20link. From owner-freebsd-net@FreeBSD.ORG Sat Apr 29 20:18:47 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA32816A402 for ; Sat, 29 Apr 2006 20:18:47 +0000 (UTC) (envelope-from elessar@bsdforen.de) Received: from postfix.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D8B643D58 for ; Sat, 29 Apr 2006 20:18:45 +0000 (GMT) (envelope-from elessar@bsdforen.de) Received: by postfix.bsdforen.de (Postfix, from userid 20000) id 8FF626844BA; Sat, 29 Apr 2006 22:18:44 +0200 (CEST) Received: from localhost (postfix [127.0.0.3]) by postfix.bsdforen.de (Postfix) with ESMTP id C8AEC6844B7 for ; Sat, 29 Apr 2006 22:18:43 +0200 (CEST) Received: from postfix.bsdforen.de ([127.0.0.3]) by localhost (postfix.bsdforen.de [127.0.0.3]) (amavisd-new, port 10024) with LMTP id 20214-04 for ; Sat, 29 Apr 2006 22:18:43 +0200 (CEST) Received: from loki (p549CD7BD.dip.t-dialin.net [84.156.215.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by postfix.bsdforen.de (Postfix) with ESMTP id 2A3F26844B6 for ; Sat, 29 Apr 2006 22:18:41 +0200 (CEST) Date: Sat, 29 Apr 2006 22:18:39 +0200 From: Joerg Pernfuss To: freebsd-net@freebsd.org Message-ID: <20060429221839.0f4ffddf@loki> X-Mailer: Sylpheed-Claws 1.9.100 (GTK+ 2.8.9; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=MP_gzGIY2r7rx9aWio+ZOE2Dus X-Virus-Scanned: amavisd-new at bsdforen.de X-DSPAM-Result: Innocent X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4453ca24252504243770684 X-DSPAM-User: global Subject: [6.1-RC] xl(4) 'command never completed' infinite loop on shutdown X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2006 20:18:47 -0000 --MP_gzGIY2r7rx9aWio+ZOE2Dus Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi guys, when I upgraded my Laptop (ThinkPad 600) to FreeBSD 6.0 I had some issues with my pccard based ethernet. These were somewhat resolved with advice I got from mobile@. Setting=20 hw.cbb.start_memory=3D0xd8000 hw.pci.link.LNKA.irq=3D11 hw.pci.link.LNKB.irq=3D11 hw.pci.link.LNKC.irq=3D11 hw.pci.link.LNKD.irq=3D11 in /boot/loader.conf eased the pain. Yesterday i updated my sources to the latest RELENG_6 and thought I'd give it a try without that bandaid. With device polling and net.isr.direct=3D1 my 3com 3CCFE575BT based ethernet (serviced by xl(4)) flies with around 6MiByte/s and the system is still as responsive as if nothing happens. Great work. One minor nit though, upon shutdown, after the buffers are synced and the uptime was reported, the systems prints 'xl0: command never completed!' forever. Actually I aborted after 5 minutes, but I doubt the behaviour would have changed significantly if I waited another 10 minutes. Attached you find: - verbose dmesg - /boot/loader.conf - kernel config (MJOELNIR) I shouldn't forget to mention, the system has daichi@'s unionfs patchset 11 applied. Other than that, stock sources. Mail archives and google were inconclusive so far. Any ideas? Meanwhile I'll play a bit with my serial cable, maybe I can get some output from a shutdown stage that late. Regards, J=F6rg --=20 | /"\ ASCII ribbon | GnuPG Key ID | e86d b753 3deb e749 6c3a | | \ / campaign against | 0xbbcaad24 | 5706 1f7d 6cfd bbca ad24 | | X HTML in email | .the next sentence is true. | | / \ and news | .the previous sentence was a lie. | --MP_gzGIY2r7rx9aWio+ZOE2Dus Content-Type: application/octet-stream; name=MJOELNIR Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=MJOELNIR IyBGcmVlQlNEL2kzODYgNi4xIEtlcm5lbCBDb25maWcgRmlsZQoKIyMgQkFTSUMgU1RVRkYKbWFj aGluZQkJaTM4NgpjcHUJCUk2ODZfQ1BVCmlkZW50CQlNSk9FTE5JUgpkZXZpY2UJCW5weApkZXZp Y2UgCQljcnlwdG8KZGV2aWNlCQljcnlwdG9kZXYKZGV2aWNlCQlybmR0ZXN0Cm1heHVzZXJzIAk1 Cm9wdGlvbnMJCVJPT1RERVZOQU1FPVwidWZzOmFkMHMxYVwiCgojIyBCQVNJQyBPUFRJT05TCm9w dGlvbnMgCV9LUE9TSVhfUFJJT1JJVFlfU0NIRURVTElORwpvcHRpb25zCQlLQkRfSU5TVEFMTF9D REVWCm9wdGlvbnMJCUhaPSIxMDAiCm9wdGlvbnMJCUtTVEFDS19QQUdFUz0zCm9wdGlvbnMJCVBS RUVNUFRJT04Kb3B0aW9ucwkJQURBUFRJVkVfR0lBTlQKZGV2aWNlCQlhcGljCm9wdGlvbnMJCUNM S19VU0VfSTgyNTRfQ0FMSUJSQVRJT04KZGV2aWNlCQlhY3BpCmRldmljZQkJYWNwaV92aWRlbwoK IyMgTUFOREFUT1JZIEFDQ0VTUyBDT05UUk9MCm9wdGlvbnMJCU1BQwpvcHRpb25zCQlNQUNfQklC QQpvcHRpb25zCQlNQUNfQlNERVhURU5ERUQKb3B0aW9ucwkJTUFDX0lGT0ZGCm9wdGlvbnMJCU1B Q19MT01BQwpvcHRpb25zCQlNQUNfTUxTCm9wdGlvbnMJCU1BQ19QQVJUSVRJT04Kb3B0aW9ucwkJ TUFDX1BPUlRBQ0wKb3B0aW9ucwkJTUFDX1NFRU9USEVSVUlEUwoKIyMgQ1BVIE9QVElPTlMKb3B0 aW9ucwkJQ1BVX0ZBU1RFUl81WDg2X0ZQVQpvcHRpb25zCQlDUFVfVVBHUkFERV9IV19DQUNIRQpv cHRpb25zCQlDUFVfRElTQUJMRV81WDg2X0xTU0VSCm9wdGlvbnMJCVBRX0NBQ0hFU0laRT01MTIK b3B0aW9ucwkJTk9fRjAwRl9IQUNLCgojIyBTWVNURU0gVFVOSU5HCm9wdGlvbnMJCU1BWFNTSVo9 KDY0VUwqMTAyNCoxMDI0KQpvcHRpb25zCQlNQVhEU0laPSg4MFVMKjEwMjQqMTAyNCkKb3B0aW9u cwkJREZMRFNJWj0oNjRVTCoxMDI0KjEwMjQpCgojIyBHRU9NL0dCREUgRW5jcnlwdGVkIERpc2Mg U3VwcG9ydApvcHRpb25zCQlHRU9NX0JERQpvcHRpb25zCQlHRU9NX0VMSQpvcHRpb25zCQlHRU9N X0JTRApvcHRpb25zCQlHRU9NX01CUgpvcHRpb25zCQlHRU9NX1ZPTApvcHRpb25zCQlHRU9NX0dB VEUKb3B0aW9ucwkJR0VPTV9NSVJST1IKb3B0aW9ucwkJR0VPTV9MQUJFTAoKIyMgQ09NUEFUSUJJ TElUWQpvcHRpb25zIAlDT01QQVRfNDMKb3B0aW9ucwkJQ09NUEFUX0ZSRUVCU0Q1Cm9wdGlvbnMJ CUNPTVBBVF9GUkVFQlNENApvcHRpb25zIAlTWVNWU0hNCm9wdGlvbnMgCVNZU1ZNU0cKb3B0aW9u cyAJU1lTVlNFTQoKIyMgU2NoZWR1bGVyIENob2ljZQpvcHRpb25zIAlTQ0hFRF80QlNECgojIyBO RVRXT1JLSU5HCm9wdGlvbnMgCUlORVQKb3B0aW9ucwkJSU5FVDYKb3B0aW9ucwkJRkFTVF9JUFNF QwpvcHRpb25zCQlERVZJQ0VfUE9MTElORwpvcHRpb25zCQlaRVJPX0NPUFlfU09DS0VUUwpvcHRp b25zCQlUQ1BfRFJPUF9TWU5GSU4Kb3B0aW9ucwkJSVBTVEVBTFRICm9wdGlvbnMJCVRDUF9TSUdO QVRVUkUKCiMjIFBBQ0tFVCBGSUxURVIgLyBUUkFGRklDIFNIQVBFUgpkZXZpY2UJCXBmCmRldmlj ZQkJcGZsb2cKZGV2aWNlCQljYXJwCm9wdGlvbnMJCUFMVFEKb3B0aW9ucwkJQUxUUV9IRlNDCm9w dGlvbnMJCUFMVFFfUFJJUQoKIyMgQkVSS0xFWSBQQUNLRVQgRklMVEVSCmRldmljZQkJYnBmCgoj IyBGSUxFLVNZU1RFTVMKb3B0aW9ucyAJRkZTCm9wdGlvbnMgCU1TRE9TRlMKb3B0aW9ucyAJQ0Q5 NjYwCm9wdGlvbnMJCVVOSU9ORlMKCiMjIFVGUyBPcHRpb25zCiNvcHRpb25zCQlRVU9UQQpvcHRp b25zIAlTT0ZUVVBEQVRFUwpvcHRpb25zIAlVRlNfQUNMCm9wdGlvbnMgCVVGU19ESVJIQVNICm9w dGlvbnMJCU1TRE9TRlNfSUNPTlYKb3B0aW9ucwkJQ0Q5NjYwX0lDT05WCgoKIyMgU1lTVEVNIEJV U1NFUwpkZXZpY2UJCWlzYQpkZXZpY2UJCXBjaQpkZXZpY2UJCXNjYnVzCmRldmljZQkJdXNiCmRl dmljZQkJbWlpYnVzCgojIyBDT05UUk9MTEVSUwpkZXZpY2UJCWZkYwpkZXZpY2UJCWF0YQpkZXZp Y2UJCWF0a2JkYwoKIyMgRGV2aWNlcwpkZXZpY2UJCXVhcnQKZGV2aWNlCQlhdGFkaXNrCmRldmlj ZQkJYXRhcGljZApkZXZpY2UJCWRhCmRldmljZQkJYXRrYmQKZGV2aWNlCQl2Z2EKZGV2aWNlCQlz YwpkZXZpY2UJCXJhbmRvbQpkZXZpY2UJCW1lbQpkZXZpY2UJCWlvCmRldmljZQkJeGwKZGV2aWNl CQl1aGNpCmRldmljZQkJdWdlbgpkZXZpY2UJCXVtYXNzCmRldmljZQkJdW1zCmRldmljZQkJcG10 aW1lcgpkZXZpY2UJCXNwbGFzaApkZXZpY2UJCXBzbQpkZXZpY2UJCXNvdW5kCmRldmljZQkJInNu ZF9tc3MiCmRldmljZQkJdmxhbgpkZXZpY2UJCXdsYW4KZGV2aWNlCQl3bGFuX3dlcApkZXZpY2UJ CXdsYW5fY2NtcApkZXZpY2UJCXdsYW5fdGtpcApkZXZpY2UJCXdsYW5feGF1dGgKZGV2aWNlCQl3 bGFuX2FjbAkJCgojIyBERVZJQ0UgT1BUSU9OUwpvcHRpb25zIAlBVEFfU1RBVElDX0lECm9wdGlv bnMJCVNDX1BJWEVMX01PREUKb3B0aW9ucwkJVkdBX1dJRFRIOTAKb3B0aW9ucwkJVkVTQQpvcHRp b25zCQlBQ0NFUFRfRklMVEVSX0hUVFAKb3B0aW9ucwkJQUNDRVBUX0ZJTFRFUl9EQVRBCgojIyBQ U0VVRE8gREVWSUNFUwpkZXZpY2UJCWxvb3AKZGV2aWNlCQlldGhlcgpkZXZpY2UJCXR1bgpkZXZp Y2UJCXBwcApkZXZpY2UJCXB0eQpkZXZpY2UJCW1kCmRldmljZQkJc25wCmRldmljZQkJdGFwCmRl dmljZQkJaW8KZGV2aWNlCQlnaWYKZGV2aWNlCQlmYWl0aApkZXZpY2UJCXN0ZgoKIyMgUENNQ0lB CmRldmljZQkJY2JiCmRldmljZSAJCWNhcmRidXMKCiMjIFVOU09SVEVEIC8gVFJZIE9VVApvcHRp b25zCQlMSUJJQ09OVgpvcHRpb25zCQlBVEtCRF9ERkxUX0tFWU1BUAptYWtlb3B0aW9ucwlBVEtC RF9ERkxUX0tFWU1BUD0iZ2VybWFuLmlzbyIKb3B0aW9ucwkJUFNNX0hPT0tSRVNVTUUKb3B0aW9u cwkJUFNNX1JFU0VUQUZURVJTVVNQRU5ECm9wdGlvbnMJCUxJQkFMSUFTCmRldmljZQkJc21idXMK ZGV2aWNlCQlpaWNzbWIKZGV2aWNlCQlpbnRwbQpkZXZpY2UJCWljaHNtYgpkZXZpY2UJCWlpY2J1 cwpkZXZpY2UJCWlpY2JiCmRldmljZQkJaWMKZGV2aWNlCQlpaWMKZGV2aWNlCQl2dApkZXZpY2UJ CWNwdWZyZXEKZGV2aWNlCQlhcG0KZGV2aWNlCQlwbXRpbWVyCg== --MP_gzGIY2r7rx9aWio+ZOE2Dus Content-Type: application/octet-stream; name=loader.conf Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=loader.conf c3BsYXNoX2JtcF9sb2FkPSJZRVMiCnNuZF9tc3NfbG9hZD0iWUVTIgpiaXRtYXBfbG9hZD0iWUVT IgpiaXRtYXBfbmFtZT0iL2Jvb3Qvc3BsYXNoLmJtcCIKYXV0b2Jvb3RfZGVsYXk9IjUiCmxvYWRl cl9jb2xvcj0iWUVTIgpkZWJ1Zy5tcHNhZmVuZXQ9IjEiCm5ldC5pc3IuZGlyZWN0PSIxIgpody5h dGEuYXRhX2RtYT0iMSIKaHcuYXRhLmF0YXBpX2RtYT0iMSIKa2Vybi5tYXhwcm9jPSIzMDAiCmtl cm4ubWF4cHJvY3BlcnVpZD0iMTAwIgo= --MP_gzGIY2r7rx9aWio+ZOE2Dus Content-Type: application/octet-stream; name=verbose_dmesg.txt Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=verbose_dmesg.txt Q29weXJpZ2h0IChjKSAxOTkyLTIwMDYgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDYuMS1SQyAjMTogU2F0IEFwciAyOSAxMjozNjozMCBDRVNU IDIwMDYKICAgIHJvb3RAbWpvZWxuaXIuc3RhcmtzdHJvbS5sYW46L3Vzci9vYmovdXNyL3NyYy9z eXMvTUpPRUxOSVIKUHJlbG9hZGVkIGVsZiBrZXJuZWwgIi9ib290L2tlcm5lbC9rZXJuZWwiIGF0 IDB4YzBhMDUwMDAuClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvc3BsYXNoX2Jt cC5rbyIgYXQgMHhjMGEwNTE3NC4KUHJlbG9hZGVkIHNwbGFzaF9pbWFnZV9kYXRhICIvYm9vdC9z cGxhc2guYm1wIiBhdCAweGMwYTA1MjI0LgpDYWxpYnJhdGluZyBjbG9jayhzKSAuLi4gaTgyNTQg Y2xvY2s6IDExOTMxMDUgSHoKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzEwNSBI eiBxdWFsaXR5IDAKQ2FsaWJyYXRpbmcgVFNDIGNsb2NrIC4uLiBUU0MgY2xvY2s6IDI5ODQwMzIw NCBIegpDUFU6IFBlbnRpdW0gSUkvUGVudGl1bSBJSSBYZW9uL0NlbGVyb24gKDI5OC40MC1NSHog Njg2LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDY1MiAgU3Rl cHBpbmcgPSAyCiAgRmVhdHVyZXM9MHgxODNmOWZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFF LE1DRSxDWDgsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixNTVgsRlhTUj4KcmVhbCBt ZW1vcnkgID0gMTM0MDIxMTIwICgxMjcgTUIpClBoeXNpY2FsIG1lbW9yeSBjaHVuayhzKToKMHgw MDAwMDAwMDAwMDAxMDAwIC0gMHgwMDAwMDAwMDAwMDllZmZmLCA2NDcxNjggYnl0ZXMgKDE1OCBw YWdlcykKMHgwMDAwMDAwMDAwMTAwMDAwIC0gMHgwMDAwMDAwMDAwM2ZmZmZmLCAzMTQ1NzI4IGJ5 dGVzICg3NjggcGFnZXMpCjB4MDAwMDAwMDAwMGMyNjAwMCAtIDB4MDAwMDAwMDAwN2Q1OGZmZiwg MTE4Njk3OTg0IGJ5dGVzICgyODk3OSBwYWdlcykKYXZhaWwgbWVtb3J5ID0gMTIxNjgzOTY4ICgx MTYgTUIpCmJpb3MzMjogRm91bmQgQklPUzMyIFNlcnZpY2UgRGlyZWN0b3J5IGhlYWRlciBhdCAw eGMwMGZkODAwCmJpb3MzMjogRW50cnkgPSAweGZkODIwIChjMDBmZDgyMCkgIFJldiA9IDAgIExl biA9IDEKcGNpYmlvczogUENJIEJJT1MgZW50cnkgYXQgMHhmZDg4MCsweDAKcG5wYmlvczogRm91 bmQgUG5QIEJJT1MgZGF0YSBhdCAweGMwMGZlNzAwCnBucGJpb3M6IEVudHJ5ID0gZjAwMDA6ZTcy NCAgUmV2ID0gMS4wCnBucGJpb3M6IEV2ZW50IGZsYWcgYXQgNDE1Ck90aGVyIEJJT1Mgc2lnbmF0 dXJlcyBmb3VuZDoKU2VjdXJpdHkgcG9saWN5IGxvYWRlZDogVHJ1c3RlZEJTRCBNQUMvaWZvZmYg KG1hY19pZm9mZikKU2VjdXJpdHkgcG9saWN5IGxvYWRlZDogVHJ1c3RlZEJTRCBNQUMvTUxTICht YWNfbWxzKQpTZWN1cml0eSBwb2xpY3kgbG9hZGVkOiBUcnVzdGVkQlNEIE1BQy9CaWJhIChtYWNf YmliYSkKU2VjdXJpdHkgcG9saWN5IGxvYWRlZDogVHJ1c3RlZEJTRCBNQUMvTE9NQUMgKG1hY19s b21hYykKU2VjdXJpdHkgcG9saWN5IGxvYWRlZDogVHJ1c3RlZEJTRCBNQUMvQlNEIEV4dGVuZGVk IChtYWNfYnNkZXh0ZW5kZWQpClNlY3VyaXR5IHBvbGljeSBsb2FkZWQ6IFRydXN0ZWRCU0QgTUFD L3NlZW90aGVydWlkcyAobWFjX3NlZW90aGVydWlkcykKU2VjdXJpdHkgcG9saWN5IGxvYWRlZDog VHJ1c3RlZEJTRCBNQUMvUGFydGl0aW9uIChtYWNfcGFydGl0aW9uKQpTZWN1cml0eSBwb2xpY3kg bG9hZGVkOiBUcnVzdGVkQlNEIE1BQy9wb3J0YWNsICh0cnVzdGVkYnNkX21hY19wb3J0YWNsKQp3 bGFuOiA8ODAyLjExIE1BQyBBQ0wgc3VwcG9ydD4Kd2xhbjogbWFjIGFjbCBwb2xpY3kgcmVnaXN0 ZXJlZAp3bGFuOiA8ODAyLjExIExpbmsgTGF5ZXI+CmNyeXB0bzogPGNyeXB0byBjb3JlPgpudWxs OiA8bnVsbCBkZXZpY2UsIHplcm8gZGV2aWNlPgpyYW5kb206IDxlbnRyb3B5IHNvdXJjZSwgU29m dHdhcmUsIFlhcnJvdz4KaW86IDxJL08+Cm1lbTogPG1lbW9yeT4KUGVudGl1bSBQcm8gTVRSUiBz dXBwb3J0IGVuYWJsZWQKVkVTQTogaW5mb3JtYXRpb24gYmxvY2sKNTYgNDUgNTMgNDEgMDAgMDIg MWYgMDEgMDAgMDEgMDAgMDAgMDAgMDAgMjIgMDAgCjAwIDAxIDFmIDAwIDFjIDAxIDAwIDAxIDAw IDAxIDA5IDAxIDAwIDAxIDFhIDAxIAowMCAwMSAwMCAwMSAwMSAwMSAwMiAwMSAwMyAwMSAwNCAw MSAwNSAwMSAwZCAwMSAKMGUgMDEgMTAgMDEgMTEgMDEgMTIgMDEgMTMgMDEgMTQgMDEgMTUgMDEg MTYgMDEgClZFU0E6IDIyIG1vZGUocykgZm91bmQKVkVTQTogdjIuMCwgMTk4NGsgbWVtb3J5LCBm bGFnczoweDAsIG1vZGUgdGFibGU6MHhjMDg4MWIyMiAoMTAwMDAyMikKVkVTQTogTWFnaWNHcmFw aCAxMjhYRCA0MEsgU1ZHQSBCSU9TClZFU0E6IE5lb01hZ2ljIE1hZ2ljR3JhcGggMTI4WFYgMDEu MApzcGxhc2g6IGltYWdlQDB4YzA5NDMyMDQsIHNpemU6Nzg3NTA2CnNwbGFzaF9ibXA6IGJleW9u ZCBzY3JlZW4gY2FwYWNpdHkgKDEwMjR4NzY4LCAyNTUgY29sb3JzKQpzcGxhc2hfYm1wOiBiZXlv bmQgc2NyZWVuIGNhcGFjaXR5ICgxMDI0eDc2OCwgMjU1IGNvbG9ycykKYm1wX3N0YXJ0KCk6IHNw bGFzaF9tb2RlOjI2MQpzcGxhc2g6IGltYWdlIGRlY29kZXIgZm91bmQ6IHNwbGFzaF9ibXAKYWNw aTA6IDxJQk0gVFA2MDA+IG9uIG1vdGhlcmJvYXJkCnBjaV9vcGVuKDEpOgltb2RlIDEgYWRkciBw b3J0ICgweDBjZjgpIGlzIDB4MDAwMDAwNjQKcGNpX29wZW4oMWEpOgltb2RlMXJlcz0weDgwMDAw MDAwICgweDgwMDAwMDAwKQpwY2lfY2ZnY2hlY2s6CWRldmljZSAwIFtjbGFzcz0wNjAwMDBdIFto ZHI9MDBdIGlzIHRoZXJlIChpZD03MTkyODA4NikKcGNpYmlvczogQklPUyB2ZXJzaW9uIDIuMTAK Rm91bmQgJFBJUiB0YWJsZSwgNCBlbnRyaWVzIGF0IDB4YzAwZjllMTAKUENJLU9ubHkgSW50ZXJy dXB0czogbm9uZQpMb2NhdGlvbiAgQnVzIERldmljZSBQaW4gIExpbmsgIElSUXMKZW1iZWRkZWQg ICAgMCAgICA3ICAgIEEgICAweDYwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQplbWJlZGRl ZCAgICAwICAgIDcgICAgRCAgIDB4NjMgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CmVtYmVk ZGVkICAgIDAgICAgMiAgICBBICAgMHg2MCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKZW1i ZWRkZWQgICAgMCAgICAyICAgIEIgICAweDYxICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpl bWJlZGRlZCAgICAwICAgIDMgICAgQSAgIDB4NjAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1 CmVtYmVkZGVkICAgIDAgICAgNCAgICBBICAgMHg2MCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQg MTUKZW1iZWRkZWQgICAgMCAgICA0ICAgIEIgICAweDYxICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAx NCAxNQplbWJlZGRlZCAgICAwICAgIDQgICAgQyAgIDB4NjIgIDMgNCA1IDYgNyA5IDEwIDExIDEy IDE0IDE1CmVtYmVkZGVkICAgIDAgICAgNCAgICBEICAgMHg2MyAgMyA0IDUgNiA3IDkgMTAgMTEg MTIgMTQgMTUKYWNwaV9idXNfbnVtYmVyOiByb290IGJ1cyBoYXMgbm8gX0JCTiwgYXNzdW1pbmcg MApBY3BpT3NEZXJpdmVQY2lJZDogYnVzIDAgZGV2IDEgZnVuYyAwCmFjcGkwOiBbTVBTQUZFXQph Y3BpX2J1c19udW1iZXI6IHJvb3QgYnVzIGhhcyBubyBfQkJOLCBhc3N1bWluZyAwCkFjcGlPc0Rl cml2ZVBjaUlkOiBidXMgMCBkZXYgMSBmdW5jIDMKYWNwaV9idXNfbnVtYmVyOiByb290IGJ1cyBo YXMgbm8gX0JCTiwgYXNzdW1pbmcgMApBY3BpT3NEZXJpdmVQY2lJZDogYnVzIDAgZGV2IDIgZnVu YyAwCmFjcGlfYnVzX251bWJlcjogcm9vdCBidXMgaGFzIG5vIF9CQk4sIGFzc3VtaW5nIDAKQWNw aU9zRGVyaXZlUGNpSWQ6IGJ1cyAwIGRldiAyIGZ1bmMgMQphY3BpX2J1c19udW1iZXI6IHJvb3Qg YnVzIGhhcyBubyBfQkJOLCBhc3N1bWluZyAwCkFjcGlPc0Rlcml2ZVBjaUlkOiBidXMgMCBkZXYg NyBmdW5jIDEKYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCmF0cGljOiBQcm9ncmFtbWluZyBJ UlE5IGFzIGxldmVsL2xvdwpwY2lfbGluazA6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6Cklu ZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcg OSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazA6IExpbmtzIGFmdGVyIGluaXRpYWwgdmFsaWRhdGlv bjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1 IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMDogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5k ZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5 IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5k ZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5 IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9u OgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUg NiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxOiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRl eCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkg MTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsyOiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRl eCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkg MTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsyOiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246 CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2 IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazI6IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4 ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAx MCAxMSAxMiAxNCAxNQpwY2lfbGluazM6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4 ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAx MCAxMSAxMiAxNCAxNQpwY2lfbGluazM6IExpbmtzIGFmdGVyIGluaXRpYWwgdmFsaWRhdGlvbjoK SW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYg NyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMzogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5kZXgg IElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEw IDExIDEyIDE0IDE1CmFjcGlfZWMwOiA8RW1iZWRkZWQgQ29udHJvbGxlcjogR1BFIDB4OSwgR0xL PiBwb3J0IDB4NjIsMHg2NiBvbiBhY3BpMAphY3BpX2VjMDogaW5mbzogbmV3IG1heCBkZWxheSBp cyAxMCB1cwphY3BpX2VjMDogaW5mbzogbmV3IG1heCBkZWxheSBpcyAyMCB1cwphY3BpX2VjMDog aW5mbzogbmV3IG1heCBkZWxheSBpcyAzMCB1cwphY3BpX2J1c19udW1iZXI6IHJvb3QgYnVzIGhh cyBubyBfQkJOLCBhc3N1bWluZyAwCkFjcGlPc0Rlcml2ZVBjaUlkOiBidXMgMCBkZXYgMCBmdW5j IDEKQUNQSSB0aW1lcjogMC80IDAvNCAwLzQgMC80IDAvNCAwLzQgMC80IDAvNCAwLzQgMC80IC0+ IDAKVGltZWNvdW50ZXIgIkFDUEktc2FmZSIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAx MDAwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4ZWYw OC0weGVmMGIgb24gYWNwaTAKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMAphY3BpX3Rocm90dGxl MDogPEFDUEkgQ1BVIFRocm90dGxpbmc+IG9uIGNwdTAKYWNwaV90aHJvdHRsZTA6IFBfQ05UIGZy b20gUF9CTEsgMHhlZjEwCmFjcGlfbGlkMDogPENvbnRyb2wgTWV0aG9kIExpZCBTd2l0Y2g+IG9u IGFjcGkwCmFjcGlfYnV0dG9uMDogPFNsZWVwIEJ1dHRvbj4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJ IEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApBQ1BJOiBGb3VuZCBt YXRjaGluZyBwaW4gZm9yIDAuNy5JTlREIGF0IGZ1bmMgMjogMjU1CkFDUEk6IEZvdW5kIG1hdGNo aW5nIHBpbiBmb3IgMC4yLklOVEEgYXQgZnVuYyAwOiAyNTUKQUNQSTogRm91bmQgbWF0Y2hpbmcg cGluIGZvciAwLjIuSU5UQiBhdCBmdW5jIDE6IDI1NQpBQ1BJOiBGb3VuZCBtYXRjaGluZyBwaW4g Zm9yIDAuMy5JTlRBIGF0IGZ1bmMgMDogMjU1CnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIw CnBjaTA6IHBoeXNpY2FsIGJ1cz0wCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4NzE5Miwg cmV2aWQ9MHgwMgoJYnVzPTAsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wNi0wMC0wMCwgaGRydHlw ZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4YTIwMCwgY2FjaGVsbnN6 PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyks IG1heGxhdD0weDAwICgwIG5zKQoJbWFwWzEwXTogdHlwZSAzLCByYW5nZSAzMiwgYmFzZSAwMDAw MDAwMCwgc2l6ZSAyOCwgZW5hYmxlZApmb3VuZC0+CXZlbmRvcj0weDEwNGMsIGRldj0weGFjMTYs IHJldmlkPTB4MDIKCWJ1cz0wLCBzbG90PTIsIGZ1bmM9MAoJY2xhc3M9MDYtMDctMDAsIGhkcnR5 cGU9MHgwMiwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAyMTAsIGNhY2hlbG5z ej04IChkd29yZHMpCglsYXR0aW1lcj0weGE4ICg1MDQwIG5zKSwgbWluZ250PTB4YzAgKDQ4MDAw IG5zKSwgbWF4bGF0PTB4MDMgKDc1MCBucykKCWludHBpbj1hLCBpcnE9MjU1Cglwb3dlcnNwZWMg MSAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgMSwgcmFu Z2UgMzIsIGJhc2UgMjAzMDEwMDAsIHNpemUgMTIsIGVuYWJsZWQKZm91bmQtPgl2ZW5kb3I9MHgx MDRjLCBkZXY9MHhhYzE2LCByZXZpZD0weDAyCglidXM9MCwgc2xvdD0yLCBmdW5jPTEKCWNsYXNz PTA2LTA3LTAwLCBoZHJ0eXBlPTB4MDIsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9 MHgwMjEwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQoJbGF0dGltZXI9MHhhOCAoNTA0MCBucyksIG1p bmdudD0weGMwICg0ODAwMCBucyksIG1heGxhdD0weDAzICg3NTAgbnMpCglpbnRwaW49YiwgaXJx PTI1NQoJcG93ZXJzcGVjIDEgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCgltYXBb MTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIDIwMzAwMDAwLCBzaXplIDEyLCBlbmFibGVkCmZv dW5kLT4JdmVuZG9yPTB4MTBjOCwgZGV2PTB4MDAwNCwgcmV2aWQ9MHgwMQoJYnVzPTAsIHNsb3Q9 MywgZnVuYz0wCgljbGFzcz0wMy0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9 MHgwMDA3LCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4 ODAgKDM4NDAgbnMpLCBtaW5nbnQ9MHgxMCAoNDAwMCBucyksIG1heGxhdD0weGZmICg2Mzc1MCBu cykKCWludHBpbj1hLCBpcnE9MjU1CgltYXBbMTBdOiB0eXBlIDMsIHJhbmdlIDMyLCBiYXNlIGUw MDAwMDAwLCBzaXplIDI0LCBlbmFibGVkCgltYXBbMTRdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNl IDIwMDAwMDAwLCBzaXplIDIxLCBlbmFibGVkCgltYXBbMThdOiB0eXBlIDEsIHJhbmdlIDMyLCBi YXNlIDIwMjAwMDAwLCBzaXplIDIwLCBlbmFibGVkCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2 PTB4NzExMCwgcmV2aWQ9MHgwMQoJYnVzPTAsIHNsb3Q9NywgZnVuYz0wCgljbGFzcz0wNi04MC0w MCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDBmLCBzdGF0cmVnPTB4MDI4MCwg Y2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDcx MTEsIHJldmlkPTB4MDEKCWJ1cz0wLCBzbG90PTcsIGZ1bmM9MQoJY2xhc3M9MDEtMDEtODAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyODAsIGNhY2hl bG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDMwICgxNDQwIG5zKSwgbWluZ250PTB4MDAgKDAg bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCW1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2Ug MDAwMGZjZjAsIHNpemUgIDQsIGVuYWJsZWQKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHg3 MTEyLCByZXZpZD0weDAxCglidXM9MCwgc2xvdD03LCBmdW5jPTIKCWNsYXNzPTBjLTAzLTAwLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjgwLCBjYWNo ZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgzMCAoMTQ0MCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49ZCwgaXJxPTI1NQoJbWFwWzIwXTogdHlw ZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwODQwMCwgc2l6ZSAgNSwgZW5hYmxlZApmb3VuZC0+CXZl bmRvcj0weDgwODYsIGRldj0weDcxMTMsIHJldmlkPTB4MDEKCWJ1cz0wLCBzbG90PTcsIGZ1bmM9 MwoJY2xhc3M9MDYtODAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwMywg c3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5z KSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCW1hcFs5MF06IHR5cGUg NCwgcmFuZ2UgMzIsIGJhc2UgMDAwMGVmYTAsIHNpemUgIDQsIGVuYWJsZWQKY2JiMDogPFRJMTI1 MCBQQ0ktQ2FyZEJ1cyBCcmlkZ2U+IG1lbSAweDIwMzAxMDAwLTB4MjAzMDFmZmYgYXQgZGV2aWNl IDIuMCBvbiBwY2kwCmNiYjA6IFJlc2VydmVkIDB4MTAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlw ZSAzIGF0IDB4MjAzMDEwMDAKY2FyZGJ1czA6IDxDYXJkQnVzIGJ1cz4gb24gY2JiMApwY2liMDog bWF0Y2hlZCBlbnRyeSBmb3IgMC4yLklOVEEgKHNyYyBcXF9TQl8uTE5LQTowKQpwY2lfbGluazA6 IFBpY2tlZCBJUlEgOSB3aXRoIHdlaWdodCAwCnBjaWIwOiBzbG90IDIgSU5UQSByb3V0ZWQgdG8g aXJxIDkgdmlhIFxcX1NCXy5MTktBCmNiYjA6IFtNUFNBRkVdCmNiYjA6IFBDSSBDb25maWd1cmF0 aW9uIHNwYWNlOgogIDB4MDA6IDB4YWMxNjEwNGMgMHgwMjEwMDAwNyAweDA2MDcwMDAyIDB4MDA4 MmE4MDggCiAgMHgxMDogMHgyMDMwMTAwMCAweDAyMDAwMGEwIDB4YjAwMzAxMDAgMHhmZmZmZjAw MCAKICAweDIwOiAweDAwMDAwMDAwIDB4ZmZmZmYwMDAgMHgwMDAwMDAwMCAweDAwMDBmZmZjIAog IDB4MzA6IDB4MDAwMDAwMDAgMHgwMDAwZmZmYyAweDAwMDAwMDAwIDB4MDc0MDAxMDkgCiAgMHg0 MDogMHgwMDkyMTAxNCAweDAwMDAwMDAxIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweDUwOiAw eDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4NjA6IDB4MDAw MDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHg3MDogMHgwMDAwMDAw MCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweDgwOiAweDAwNDQ5MDYxIDB4 MDAwMDAwMDAgMHgwMTgxODE0OCAweGZiYTk3NTQzIAogIDB4OTA6IDB4NjA2MjAyYzAgMHgwMDAw MDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHhhMDogMHg3ZTIxMDAwMSAweDAwODAwMDAw IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweGIwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgw MDAwMDAwMCAweDAwMDAwMDAwIAogIDB4YzA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAw MDAwIDB4MDAwMDAwMDAgCiAgMHhkMDogMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAg MHgwMDAwMDAwMCAKICAweGUwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAw MDAwMDAwIAogIDB4ZjA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAw MDAgCmNiYjE6IDxUSTEyNTAgUENJLUNhcmRCdXMgQnJpZGdlPiBtZW0gMHgyMDMwMDAwMC0weDIw MzAwZmZmIGF0IGRldmljZSAyLjEgb24gcGNpMApjYmIxOiBSZXNlcnZlZCAweDEwMDAgYnl0ZXMg Zm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweDIwMzAwMDAwCmNhcmRidXMxOiA8Q2FyZEJ1cyBidXM+ IG9uIGNiYjEKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMi5JTlRCIChzcmMgXFxfU0JfLkxO S0I6MCkKcGNpX2xpbmsxOiBQaWNrZWQgSVJRIDkgd2l0aCB3ZWlnaHQgMwpwY2liMDogc2xvdCAy IElOVEIgcm91dGVkIHRvIGlycSA5IHZpYSBcXF9TQl8uTE5LQgpjYmIxOiBbTVBTQUZFXQpjYmIx OiBQQ0kgQ29uZmlndXJhdGlvbiBzcGFjZToKICAweDAwOiAweGFjMTYxMDRjIDB4MDIxMDAwMDcg MHgwNjA3MDAwMiAweDAwODJhODA4IAogIDB4MTA6IDB4MjAzMDAwMDAgMHgwMjAwMDBhMCAweGIw MDYwNDAwIDB4ZmZmZmYwMDAgCiAgMHgyMDogMHgwMDAwMDAwMCAweGZmZmZmMDAwIDB4MDAwMDAw MDAgMHgwMDAwZmZmYyAKICAweDMwOiAweDAwMDAwMDAwIDB4MDAwMGZmZmMgMHgwMDAwMDAwMCAw eDA3NDAwMjA5IAogIDB4NDA6IDB4MDA5MjEwMTQgMHgwMDAwMDAwMSAweDAwMDAwMDAwIDB4MDAw MDAwMDAgCiAgMHg1MDogMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAw MCAKICAweDYwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAog IDB4NzA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHg4 MDogMHgwMDQ0YjA2MSAweDAwMDAwMDAwIDB4MDE4MTgxNDggMHhmYmE5NzU0MyAKICAweDkwOiAw eDYwNjIwMmMwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4YTA6IDB4N2Uy MTAwMDEgMHgwMDgwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHhiMDogMHgwMDAwMDAw MCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweGMwOiAweDAwMDAwMDAwIDB4 MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4ZDA6IDB4MDAwMDAwMDAgMHgwMDAw MDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHhlMDogMHgwMDAwMDAwMCAweDAwMDAwMDAw IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweGYwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgw MDAwMDAwMCAweDAwMDAwMDAwIAphY3BpX3ZpZGVvMDogPEFDUEkgdmlkZW8gZXh0ZW5zaW9uPiBt ZW0gMHhlMDAwMDAwMC0weGUwZmZmZmZmLDB4MjAwMDAwMDAtMHgyMDFmZmZmZiwweDIwMjAwMDAw LTB4MjAyZmZmZmYgYXQgZGV2aWNlIDMuMCBvbiBwY2kwCmZvdW5kIExDRCBwYW5lbCgxMTApLCBk ZXRlY3RhYmxlIGJ5IEJJT1MsIGhlYWQgIzAKZm91bmQgQ1JUIG1vbml0b3IoMTAwKSwgZGV0ZWN0 YWJsZSBieSBCSU9TLCBoZWFkICMwClBDSS1JU0EgYnJpZGdlIHdpdGggaW5jb3JyZWN0IHN1YmNs YXNzIDB4ODAKUENJLUlTQSBicmlkZ2Ugd2l0aCBpbmNvcnJlY3Qgc3ViY2xhc3MgMHg4MAppc2Fi MDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgNy4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+ IG9uIGlzYWIwCmF0YXBjaTA6IDxJbnRlbCBQSUlYNCBVRE1BMzMgY29udHJvbGxlcj4gcG9ydCAw eDFmMC0weDFmNywweDNmNiwweDE3MC0weDE3NywweDM3NiwweGZjZjAtMHhmY2ZmIGF0IGRldmlj ZSA3LjEgb24gcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgyMCB0 eXBlIDQgYXQgMHhmY2YwCmF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0YXBjaTA6 IFJlc2VydmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSA0IGF0IDB4MWYwCmF0YXBjaTA6 IFJlc2VydmVkIDB4MSBieXRlcyBmb3IgcmlkIDB4MTQgdHlwZSA0IGF0IDB4M2Y2CmF0YTA6IHJl c2V0IHRwMSBtYXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9MDAKYXRhMDogc3RhdDA9MHg1MCBlcnI9 MHgwMSBsc2I9MHgwMCBtc2I9MHgwMAphdGEwOiBzdGF0MT0weDAwIGVycj0weDAxIGxzYj0weDAw IG1zYj0weDAwCmF0YTA6IHJlc2V0IHRwMiBzdGF0MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MTxB VEFfTUFTVEVSPgphdGEwOiBbTVBTQUZFXQphdGExOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNp MAphdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDE4IHR5cGUgNCBhdCAweDE3 MAphdGFwY2kwOiBSZXNlcnZlZCAweDEgYnl0ZXMgZm9yIHJpZCAweDFjIHR5cGUgNCBhdCAweDM3 NgphdGExOiByZXNldCB0cDEgbWFzaz0wMyBvc3RhdDA9MDAgb3N0YXQxPTAwCmF0YTE6IHN0YXQw PTB4MDAgZXJyPTB4MDAgbHNiPTB4MDAgbXNiPTB4MDAKYXRhMTogc3RhdDE9MHgwMCBlcnI9MHgw MCBsc2I9MHgwMCBtc2I9MHgwMAphdGExOiByZXNldCB0cDIgc3RhdDA9MDAgc3RhdDE9MDAgZGV2 aWNlcz0weDAKYXRhMTogW01QU0FGRV0KdWhjaTA6IDxJbnRlbCA4MjM3MUFCL0VCIChQSUlYNCkg VVNCIGNvbnRyb2xsZXI+IHBvcnQgMHg4NDAwLTB4ODQxZiBhdCBkZXZpY2UgNy4yIG9uIHBjaTAK dWhjaTA6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweDg0MDAK cGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuNy5JTlREIChzcmMgXFxfU0JfLkxOS0Q6MCkKcGNp X2xpbmszOiBQaWNrZWQgSVJRIDkgd2l0aCB3ZWlnaHQgNQpwY2liMDogc2xvdCA3IElOVEQgcm91 dGVkIHRvIGlycSA5IHZpYSBcXF9TQl8uTE5LRAp1aGNpMDogW0dJQU5ULUxPQ0tFRF0KdXNiMDog PEludGVsIDgyMzcxQUIvRUIgKFBJSVg0KSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTAKdXNiMDog VVNCIHJldmlzaW9uIDEuMAp1aHViMDogSW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCBy ZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkCmludHBtMDogPEludGVsIDgyMzcxQUIgUG93ZXIgbWFuYWdlbWVudCBjb250cm9s bGVyPiBwb3J0IDB4ZWZhMC0weGVmYWYgaXJxIDkgYXQgZGV2aWNlIDcuMyBvbiBwY2kwCmludHBt MDogUmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3IgcmlkIDB4OTAgdHlwZSA0IGF0IDB4ZWZhMAppbnRw bTA6IEkvTyBtYXBwZWQgZWZhMAppbnRwbTA6IGludHIgSVJRIDkgZW5hYmxlZCByZXZpc2lvbiAw CmludHBtMDogW0dJQU5ULUxPQ0tFRF0KaW50c21iMDogPEludGVsIFBJSVg0IFNNQlVTIEludGVy ZmFjZT4gb24gaW50cG0wCnNtYnVzMTogPFN5c3RlbSBNYW5hZ2VtZW50IEJ1cz4gb24gaW50c21i MAppbnRwbTA6IFBNIEkvTyBtYXBwZWQgZWYwMCAKYWNwaV90ejA6IDxUaGVybWFsIFpvbmU+IG9u IGFjcGkwCmFjcGlfZWMwOiBpbmZvOiBuZXcgbWF4IGRlbGF5IGlzIDUwIHVzCmFjcGlfdHoxOiA8 VGhlcm1hbCBab25lPiBvbiBhY3BpMAphY3BpX3R6MjogPFRoZXJtYWwgWm9uZT4gb24gYWNwaTAK ZmRjMDogPGZsb3BweSBkcml2ZSBjb250cm9sbGVyIChGREUpPiBwb3J0IDB4M2YwLTB4M2Y1LDB4 M2Y3IGlycSA2IGRycSAyIG9uIGFjcGkwCmZkYzA6IGljX3R5cGUgOTAgcGFydF9pZCA3MwpmZGMw OiBbTVBTQUZFXQpmZGMwOiBbRkFTVF0KZmQwOiA8MTQ0MC1LQiAzLjUiIGRyaXZlPiBvbiBmZGMw IGRyaXZlIDAKdWFydDA6IDwxNjU1MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4M2Y4LTB4M2ZmIGly cSA0IG9uIGFjcGkwCnVhcnQwOiBmYXN0IGludGVycnVwdApwY20wOiA8Q1M0MjN4PiBwb3J0IDB4 NTMwLTB4NTM3LDB4Mzg4LTB4MzhiLDB4MjIwLTB4MjMzIGlycSA1IGRycSAxLDAgb24gYWNwaTAK cGNtMDogW0dJQU5ULUxPQ0tFRF0KcGNtMDogc25kYnVmX3NldG1hcCBmZjQwMDAsIDEwMDA7IDB4 YzdjYjYwMDAgLT4gZmY0MDAwCnBjbTA6IHNuZGJ1Zl9zZXRtYXAgZmYzMDAwLCAxMDAwOyAweGM3 Y2I3MDAwIC0+IGZmMzAwMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBw b3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEg b24gYXRrYmRjMAphdGtiZDogdGhlIGN1cnJlbnQga2JkIGNvbnRyb2xsZXIgY29tbWFuZCBieXRl IDAwNjUKYXRrYmQ6IGtleWJvYXJkIElEIDB4NTRhYiAoMikKa2JkMCBhdCBhdGtiZDAKa2JkMDog YXRrYmQwLCBBVCAxMDEvMTAyICgyKSwgY29uZmlnOjB4MCwgZmxhZ3M6MHgzZDAwMDAKYXRrYmQw OiBbR0lBTlQtTE9DS0VEXQpwc20wOiB1bmFibGUgdG8gYWxsb2NhdGUgSVJRCnBzbWNwbnAwOiA8 UFMvMiBtb3VzZSBwb3J0PiBpcnEgMTIgb24gYWNwaTAKcHNtMDogY3VycmVudCBjb21tYW5kIGJ5 dGU6MDA2NQpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0a2JkYzAKcHNtMDogW0dJQU5U LUxPQ0tFRF0KcHNtMDogbW9kZWwgR2VuZXJpYyBQUy8yIG1vdXNlLCBkZXZpY2UgSUQgMC0wMCwg MiBidXR0b25zCnBzbTA6IGNvbmZpZzowMDAwNjAwMCwgZmxhZ3M6MDAwMDAwMDgsIHBhY2tldCBz aXplOjMKcHNtMDogc3luY21hc2s6YzAsIHN5bmNiaXRzOjAwCmJhdHRlcnkwOiA8QUNQSSBDb250 cm9sIE1ldGhvZCBCYXR0ZXJ5PiBvbiBhY3BpMAphY3BpX2FjYWQwOiA8QUMgQWRhcHRlcj4gb24g YWNwaTAKbnB4MDogW0ZBU1RdCm5weDA6IDxtYXRoIHByb2Nlc3Nvcj4gb24gbW90aGVyYm9hcmQK bnB4MDogSU5UIDE2IGludGVyZmFjZQphdGE6IGF0YTAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5n IGl0CmF0YTogYXRhMSBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKYXRrYmRjOiBhdGtiZGMw IGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApmZGM6IGZkYzAgYWxyZWFkeSBleGlzdHM7IHNr aXBwaW5nIGl0CnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyMDMKcG5wX2lkZW50 aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDI0MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1Bv cnQgYXQgMjgzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyYzMKcG5wX2lkZW50 aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDMwMwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1Bv cnQgYXQgMzQzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzODMKcG5wX2lkZW50 aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDNjMwpQTlAgSWRlbnRpZnkgY29tcGxldGUKdnQ6IHZ0 MCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKc2M6IHNjMCBhbHJlYWR5IGV4aXN0czsgc2tp cHBpbmcgaXQKdmdhOiB2Z2EwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAppc2FfcHJvYmVf Y2hpbGRyZW46IGRpc2FibGluZyBQblAgZGV2aWNlcwppc2FfcHJvYmVfY2hpbGRyZW46IHByb2Jp bmcgbm9uLVBuUCBkZXZpY2VzCnBtdGltZXIwIG9uIGlzYTAKb3JtMDogPElTQSBPcHRpb24gUk9N PiBhdCBpb21lbSAweGMwMDAwLTB4YzlmZmYgb24gaXNhMAphZHYwOiBub3QgcHJvYmVkIChkaXNh YmxlZCkKYWhhMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmFpYzA6IG5vdCBwcm9iZWQgKGRpc2Fi bGVkKQpidDA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpjczA6IG5vdCBwcm9iZWQgKGRpc2FibGVk KQplZDA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpmZTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpp ZTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpsbmMwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKcHBj MDogbm90IHByb2JlZCAoZGlzYWJsZWQpCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAw eDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4K c2MwOiBmYjAsIGtiZDAsIHRlcm1pbmFsIGVtdWxhdG9yOiBzYyAoc3lzY29ucyB0ZXJtaW5hbCkK c2lvMCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNmOCBpcnEgNCBvbiBpc2EwCnNpbzE6IG5v dCBwcm9iZWQgKGRpc2FibGVkKQpzaW8yOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKc2lvMzogbm90 IHByb2JlZCAoZGlzYWJsZWQpCnNuMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCnZnYTA6IDxHZW5l cmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9u IGlzYTAKdnQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9i aW5nIFBuUCBkZXZpY2VzCkRldmljZSBjb25maWd1cmF0aW9uIGZpbmlzaGVkLgpUaW1lY291bnRl ciAiVFNDIiBmcmVxdWVuY3kgMjk4NDAzMjA0IEh6IHF1YWxpdHkgODAwClRpbWVjb3VudGVycyB0 aWNrIGV2ZXJ5IDEwLjAwMCBtc2VjCmNyeXB0bzogPGNyeXB0byBkZXZpY2U+CmNyeXB0bzogYXNz aWduIGRyaXZlciAwLCBmbGFncyA2CmNyeXB0bzogZHJpdmVyIDAgcmVnaXN0ZXJzIGFsZyAxIGZs YWdzIDAgbWF4b3BsZW4gMApjcnlwdG86IGRyaXZlciAwIHJlZ2lzdGVycyBhbGcgMiBmbGFncyAw IG1heG9wbGVuIDAKY3J5cHRvOiBkcml2ZXIgMCByZWdpc3RlcnMgYWxnIDMgZmxhZ3MgMCBtYXhv cGxlbiAwCmNyeXB0bzogZHJpdmVyIDAgcmVnaXN0ZXJzIGFsZyA0IGZsYWdzIDAgbWF4b3BsZW4g MApjcnlwdG86IGRyaXZlciAwIHJlZ2lzdGVycyBhbGcgNSBmbGFncyAwIG1heG9wbGVuIDAKY3J5 cHRvOiBkcml2ZXIgMCByZWdpc3RlcnMgYWxnIDE3IGZsYWdzIDAgbWF4b3BsZW4gMApjcnlwdG86 IGRyaXZlciAwIHJlZ2lzdGVycyBhbGcgNiBmbGFncyAwIG1heG9wbGVuIDAKY3J5cHRvOiBkcml2 ZXIgMCByZWdpc3RlcnMgYWxnIDcgZmxhZ3MgMCBtYXhvcGxlbiAwCmNyeXB0bzogZHJpdmVyIDAg cmVnaXN0ZXJzIGFsZyAxNSBmbGFncyAwIG1heG9wbGVuIDAKY3J5cHRvOiBkcml2ZXIgMCByZWdp c3RlcnMgYWxnIDggZmxhZ3MgMCBtYXhvcGxlbiAwCmNyeXB0bzogZHJpdmVyIDAgcmVnaXN0ZXJz IGFsZyAxNiBmbGFncyAwIG1heG9wbGVuIDAKY3J5cHRvOiBkcml2ZXIgMCByZWdpc3RlcnMgYWxn IDkgZmxhZ3MgMCBtYXhvcGxlbiAwCmNyeXB0bzogZHJpdmVyIDAgcmVnaXN0ZXJzIGFsZyAxMCBm bGFncyAwIG1heG9wbGVuIDAKY3J5cHRvOiBkcml2ZXIgMCByZWdpc3RlcnMgYWxnIDEzIGZsYWdz IDAgbWF4b3BsZW4gMApjcnlwdG86IGRyaXZlciAwIHJlZ2lzdGVycyBhbGcgMTQgZmxhZ3MgMCBt YXhvcGxlbiAwCmNyeXB0bzogZHJpdmVyIDAgcmVnaXN0ZXJzIGFsZyAxMSBmbGFncyAwIG1heG9w bGVuIDAKY3J5cHRvOiBkcml2ZXIgMCByZWdpc3RlcnMgYWxnIDE4IGZsYWdzIDAgbWF4b3BsZW4g MApGYXN0IElQc2VjOiBJbml0aWFsaXplZCBTZWN1cml0eSBBc3NvY2lhdGlvbiBQcm9jZXNzaW5n LgpsbzA6IGJwZiBhdHRhY2hlZApwZmxvZzA6IGJwZiBhdHRhY2hlZApiYXR0ZXJ5MDogYmF0dGVy eSBpbml0aWFsaXphdGlvbiBzdGFydAphY3BpX2FjYWQwOiBhY2xpbmUgaW5pdGlhbGl6YXRpb24g c3RhcnQKY2FyZGJ1czE6IFJlc291cmNlIG5vdCBzcGVjaWZpZWQgaW4gQ0lTOiBpZD0xNCwgc2l6 ZT04MApjYXJkYnVzMTogUmVzb3VyY2Ugbm90IHNwZWNpZmllZCBpbiBDSVM6IGlkPTE4LCBzaXpl PTgwCmZvdW5kLT4JdmVuZG9yPTB4MTBiNywgZGV2PTB4NTE1NywgcmV2aWQ9MHgwMQoJYnVzPTQs IHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCglj bWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDIxMCwgY2FjaGVsbnN6PTggKGR3b3JkcykKCWxhdHRp bWVyPTB4YTggKDUwNDAgbnMpLCBtaW5nbnQ9MHgwYSAoMjUwMCBucyksIG1heGxhdD0weDA1ICgx MjUwIG5zKQoJaW50cGluPWEsIGlycT05Cglwb3dlcnNwZWMgMSAgc3VwcG9ydHMgRDAgRDEgRDIg RDMgIGN1cnJlbnQgRDAKeGwwOiA8M0NvbSAzYzU3NUIgRmFzdCBFdGhlcmxpbmsgWEw+IHBvcnQg MHgxMDAwLTB4MTA3ZiBtZW0gMHg4ODAwMDAwMC0weDg4MDAwMDdmLDB4ODgwMDEwMDAtMHg4ODAw MTA3ZiBpcnEgOSBhdCBkZXZpY2UgMC4wIG9uIGNhcmRidXMxCnhsMDogUmVzZXJ2ZWQgMHg4MCBi eXRlcyBmb3IgcmlkIDB4MTAgdHlwZSA0IGF0IDB4MTAwMAp4bDA6IHVzaW5nIHBvcnQgSS9PCnhs MDogUmVzZXJ2ZWQgMHg4MCBieXRlcyBmb3IgcmlkIDB4MTggdHlwZSAzIGF0IDB4ODgwMDEwMDAK eGwwOiBSZXNlcnZlZCAweDEgYnl0ZXMgZm9yIHJpZCAwIHR5cGUgMSBhdCAweDkKeGwwOiBtZWRp YSBvcHRpb25zIHdvcmQ6IDQwCnhsMDogZm91bmQgTUlJL0FVVE8KbWlpYnVzMDogPE1JSSBidXM+ IG9uIHhsMAp0ZGtwaHkwOiA8VERLIDc4UTIxMjAgbWVkaWEgaW50ZXJmYWNlPiBvbiBtaWlidXMw CnRka3BoeTA6IE9VSSAweDAwYzAzOSwgbW9kZWwgMHgwMDE0LCByZXYuIDExCnRka3BoeTA6ICAx MGJhc2VULCAxMDBiYXNlVFgsIGF1dG8KeGwwOiBicGYgYXR0YWNoZWQKeGwwOiBFdGhlcm5ldCBh ZGRyZXNzOiAwMDo1MDpkYTo5YToyZTo4Mgp4bDA6IFtNUFNBRkVdCmF0YTAtbWFzdGVyOiBwaW89 UElPNCB3ZG1hPVdETUEyIHVkbWE9VURNQTMzIGNhYmxlPTQwIHdpcmUKYWNwaV9hY2FkMDogT24g TGluZQphY3BpX2FjYWQwOiBhY2xpbmUgaW5pdGlhbGl6YXRpb24gZG9uZSwgdHJpZWQgMSB0aW1l cwphY3BpX3R6MTogX0FDMDogdGVtcGVyYXR1cmUgNDMuOCA+PSBzZXRwb2ludCAzNi41CmFjcGlf dHoxOiBzd2l0Y2hlZCBmcm9tIE5PTkUgdG8gX0FDMDogNDMuOEMKYWQwOiBzZXR0aW5nIFBJTzQg b24gUElJWDQgY2hpcAphZDA6IHNldHRpbmcgVURNQTMzIG9uIFBJSVg0IGNoaXAKYWQwOiA0ODg3 TUIgPElCTSBEQURBLTI1MTIwIEFENUlBNENBPiBhdCBhdGEwLW1hc3RlciBVRE1BMzMKYWQwOiAx MDAwOTQ0MCBzZWN0b3JzIFsxMDU5MkMvMTVILzYzU10gMTYgc2VjdG9ycy9pbnRlcnJ1cHQgMSBk ZXB0aCBxdWV1ZQpmZGMwOiBvdXRwdXQgcmVhZHkgdGltZW91dApmZGMwOiBvdXRwdXQgcmVhZHkg dGltZW91dApmZGMwOiBvdXRwdXQgcmVhZHkgdGltZW91dApmZGMwOiBvdXRwdXQgcmVhZHkgdGlt ZW91dApmZGMwOiBvdXRwdXQgcmVhZHkgdGltZW91dApmZGMwOiBvdXRwdXQgcmVhZHkgdGltZW91 dApmZGMwOiBvdXRwdXQgcmVhZHkgdGltZW91dAphY3BpX2VjMDogaW5mbzogbmV3IG1heCBkZWxh eSBpcyA2MCB1cwpiYXR0ZXJ5MDogYmF0dGVyeSBpbml0aWFsaXphdGlvbiBkb25lLCB0cmllZCAx IHRpbWVzCmZkYzA6IG91dHB1dCByZWFkeSB0aW1lb3V0CmZkYzA6IGlucHV0IHJlYWR5IHRpbWVv dXQKZmRjMDogaW5wdXQgcmVhZHkgdGltZW91dApmZGMwOiBvdXRwdXQgcmVhZHkgdGltZW91dApm ZGMwOiBpbnB1dCByZWFkeSB0aW1lb3V0CmZkYzA6IGlucHV0IHJlYWR5IHRpbWVvdXQKZmRjMDog b3V0cHV0IHJlYWR5IHRpbWVvdXQKZmRjMDogaW5wdXQgcmVhZHkgdGltZW91dApmZGMwOiBpbnB1 dCByZWFkeSB0aW1lb3V0CmZkYzA6IG91dHB1dCByZWFkeSB0aW1lb3V0CmZkYzA6IGlucHV0IHJl YWR5IHRpbWVvdXQKZmRjMDogaW5wdXQgcmVhZHkgdGltZW91dApHRU9NOiBuZXcgZGlzayBhZDAK VHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9hZDBzMWEKc3RhcnRfaW5pdDogdHJ5 aW5nIC9zYmluL2luaXQKR0VPTV9FTEk6IERldmljZSBhZDBzMWIuZWxpIGNyZWF0ZWQuCkdFT01f RUxJOiAgICAgQ2lwaGVyOiBBRVMKR0VPTV9FTEk6IEtleSBsZW5ndGg6IDI1NgpHRU9NX0VMSTog ICAgIENyeXB0bzogc29mdHdhcmUK --MP_gzGIY2r7rx9aWio+ZOE2Dus--