RELENG_7: something is very wrong with UDP?
jhb at freebsd.org
Tue Sep 23 20:19:37 UTC 2008
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 18.104.22.168
> >>> 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 22.214.171.124 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@
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.
More information about the freebsd-stable