RELENG_7: something is very wrong with UDP?

[John Baldwin]

On Saturday 20 September 2008 05:58:03 am Oleg V. Nauman wrote:
> Quoting Robert Watson <rwatson at FreeBSD.org>:
> >>> 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 at 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