the transmit watchdog. These drivers already used a private timer when
compiled to use Netgraph. This change just makes them always use the
private timer. Note that these drivers do not compile and are disconnected
from the build due to TTY changes.
if_watchdog and if_timer. The driver already contained an optional stats
timer that individual attachments could use to provide a 'tick' event. The
stats timer only ran if the tick function pointer was non-NULL and the
attachment's tick routine had to call callout_reset(), etc. Now the driver
always schedules a stat timer and manages the callout_reset() internally.
This timer is used to drive the watchdog and will also call the attachment's
'tick' handler if one is provided.
Tested by: WATANABE Kazuhiro
to fail due to lack of resources to queue siginfo. Add KSI_SIGQ flag
that allows sigqueue_add() to fail while trying to allocate memory for
new siginfo. When the flag is not set, behaviour is the same as for
KSI_TRAP: if memory cannot be allocated, set bit in sq_kill. KSI_TRAP is
kept to preserve KBI.
Add SI_KERNEL si_code, to be used in siginfo.si_code when signal is
generated by kernel. Deliver siginfo when signal is generated by kill(2)
family of syscalls (SI_USER with properly filled si_uid and si_pid), or
by kernel (SI_KERNEL, mostly job control or SIGIO). Since KSI_SIGQ flag
is not set for the ksi, low memory condition cause old behaviour.
Keep psignal(9) KBI intact, but modify it to generate SI_KERNEL
si_code. Pgsignal(9) and gsignal(9) now take ksi explicitely. Add
pksignal(9) that behaves like psignal but takes ksi, and ddb kill
command implemented as pksignal(..., ksi = NULL) to not do allocation
while in debugger.
While there, remove some register specifiers and use ANSI C prototypes.
Reviewed by: davidxu
MFC after: 1 month
BZ_STREAM_END triggered re-init. Do it by introducing a new flag
to represent the 'cold' case after bzip2 state is reinitialized.
This fixes regression reported on -current@ as well as another one
I found during twiddling with gzip.
Reported by: swell.k gmail.com
MFC after: 1 week
- Harmless typo in definitions of Antarctica/Davis
- Fiji will go to DST between 29 November 2009 and 25 April 2010
Obtained from: ftp://elsie.nci.nih.gov/pub/
and Marvell handled. Instead of trying to attach two different drivers to
single device, wrapping each call, make one of them (atajmicron, atamarvell)
attach do device solely, but create child device for AHCI driver,
passing it all required resources. It is quite easy, as none of
resources are shared, except IRQ.
As result, it:
- makes drivers operation more independent and straitforward,
- allows to use new ahci(4) driver with such devices, adding support for
new features, such as PMP and NCQ, same time keeping legacy PATA support,
- will allow to just drop old ataahci driver, when it's time come.
Userland daemons need to see IGMP traffic regardless of the group;
omit the imo filter check if the proto is IGMP. The kernel part
of IGMP will have already filtered appropriately at this point.
MFC after: ASAP
Submitted by: Franz Struwig
Reported by: Ivor Prebeg, Franz Struwig
Remove code that years ago was closing race between request submission
to SIM and device/SIM freeze. That race become impossible after moving from
spl to mutex locking, while this workaround causes some unexpected effects.
I have found that it is not only desktop CPUs problem. but mobile also.
Probably AP on laptops just started initially at lower frequency, hiding
the problem.
Disable frequency validation by default, for systems with more then one CPU,
until we can implement it properly. It looks like making more harm now then
benefits. Add 'hw.est.strict' loader tunable to control it.
Now my iXsystems Invincibook is able to run at 800MHz lowest frequency,
instead of 1200MHz before, when 800MHz was incorrectly reported invalid.
CPU core, only pair of them. As result, both cores are running on highest
one of requested frequencies, and that is reported by status register.
Such behavior confuses frequency validation logic, as it runs on only
one core, as SMP is not yet launched, making EIST completely unusable.
To workaround this, add check for validation result. If we haven't found
at least two usable frequencies, then probably we are looking bad and have
to trust data provided by BIOS as-is.
