On Saturday 20 September 2008 05:58:03 am Oleg V. Nauman wrote: > Quoting Robert Watson <[EMAIL PROTECTED]>: > >>> 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 > [EMAIL PROTECTED]) 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 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"