clang.
The general idea is that the vendor will not accept our compilation
patches and so disabling the warnings is the best way to go as it makes
future imports bearable.
Submitted by: Dimitry Andric <dimitry at andric.com>
Discussed with: das
- Daylight Saving Time will not be used in Egypt during Ramadan.
- Proper names for Pacific/Pohnpei and Pacific/Chuuk
- Fix historical information for Finland for 1981 and 1982
- No leap-second for December 2010.
- Fix historical information for Ontario (Canada)
- Daylight Saving Time will not be used in Egypt during Ramadan this year.
- Proper names for Pacific/Pohnpei and Pacific/Chuuk
- Fix historical information for Finland for 1981 and 1982
- No leap-second for December 2010.
- Fix historical information for Ontario (Canada)
Obtained from: ftp://elsie.nci.nih.gov/pub/
nd6_llinfo_timer() functions with a KASSERT().
Note: there is no need to return after panic.
In the legacy IP case, only assign the arg after the check,
in the IPv6 case, remove the extra checks for the table and
interface as they have to be there unless we freed and forgot
to cancel the timer. It doesn't matter anyway as we would
panic on the NULL pointer deref immediately and the bug is
elsewhere.
This unifies the code of both address families to some extend.
Reviewed by: rwatson
MFC after: 6 days
* breakpoint setup support
* register query
* symbol to address mapping and vice-versa
* more misc utility functions based on their Solaris counterpart
Also, I've written some test cases.
Sponsored by: The FreeBSD Foundation
Free the rtentry after we diconnected it from the FIB and are counting
it as rttrash. There might still be a chance we leak it from a different
code path but there is nothing we can do about this here.
Sponsored by: ISPsystem (in February)
Reviewed by: julian (in February)
MFC after: 2 weeks
was limited to one segment under the faulty assumption of a retransmit.
Due to this the opportunity to initialize the increased congestion window
according to RFC3390 was missed.
Support for RFC3465 introduced in r187289 uncovered the bug as the ACK
to SYN/ACK no longer caused snd_cwnd increase by MSS (actually, this
increase shouldn't happen as it's explicitly forbidden by RFC3390, but
it's another issue). Snd_cwnd remains really small (1*MSS + 1) and this
causes really bad interaction with delayed acks on other side.
The variable name sc_rxmits is a bit misleading as it counts all transmits,
not just retransmits.
Submitted by: Maxim Dounin <mdounin-at-mdounin-dot-ru>
MFC after: 10 days