From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 20:19:37 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF53010656AD; Tue, 23 Sep 2008 20:19:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6E18FC2B; Tue, 23 Sep 2008 20:19:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8NKJOvl075249; Tue, 23 Sep 2008 16:19:31 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 23 Sep 2008 16:12:00 -0400 User-Agent: KMail/1.9.7 References: <20080918180543.pt7s2zmaio48ww8g@webmail.opentransfer.com> <20080920125803.d81jiet544cgc8g4@webmail.opentransfer.com> In-Reply-To: <20080920125803.d81jiet544cgc8g4@webmail.opentransfer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809231612.00996.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 23 Sep 2008 16:19:31 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8317/Tue Sep 23 15:48:36 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Robert Watson Subject: Re: RELENG_7: something is very wrong with UDP? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2008 20:19:37 -0000 On Saturday 20 September 2008 05:58:03 am Oleg V. Nauman wrote: > Quoting Robert Watson : > >>> This is approximately the date of my last UDP MFC. Could you try > >>> backing out just src/sys/netinet6/udp6_usrreq.c revision 1.81.2.7 > >>> and see if that helps? (specifically, restore the use of > >>> sosend_generic instead of sosend_dgram) > > > > If you can show that it's definitely a problem with the change to > > sosend_dgram for UDPv6 socket send, then it might suggest it's the same > > problem that it is related to the UDPv46 code there. In which case I > > will propose we back out that portion of the change in the 7-stable > > branch until it's known to be resolved -- I don't want other people > > tripping over this. > > Sorry for false alarm regarding UDP issues.. Have noticed that my > clock is stop incrementing ( it explaining the zeroes in traceroute > output also ). It gave me idea what is related to this issue so > performed backout revision 1.243.2.4 of src/sys/dev/acpica/acpi.c and > it fixes my issues.. Looks like it stops incrementing the timecounters > on my laptop.. > Ironically speaking I was this ACPI behavior change initiator ( I was > reporting "ACPI HPET stops working on my RELENG_7" at July 19 to > stable@freebsd.org) so jhb@ implemented a patch and it was working for > me those days. Something was changed during the next 2 months so this > patch causing issues instead the success on my hardware. I will play a > bit with kern.timecounter.choice at Monday and report it back to jhb@ > then. The HPET is only used for "time of day". It does not drive the internal timers used by the kernel. If you find that the latest acpi.c makes a difference, you will need to start with before and after verbose dmesgs. -- John Baldwin