performance critical path, it's more important to ensure it will succeed
eventually; also return EAGAIN rather than ENOMEM, so the I/O will be
retried by dk_start() when previous I/O finishes
fix yet another leak on the xengnt_grant_access() fail path in
xbd_diskstart() - this time the unalign buffer
repository, don't attempt to install it, and don't expect it to
be installed. If a better fix is to return 02-dump, then this
change can be reverted (by anyone, just go ahead and do it).
dhcpcd(8) should also have mention of 02-dump removed, if removing
it was intentional.
are bound to a different CPU at creation time).
Recent MI changes caused the scheduler to choose a different CPU when
probing and attaching xennet devices (I guess it's the xenbus thread which
runs on a different CPU). This cause the callback to be called on a different
CPU than the one expected by the kernel, and the event is ignored.
It is handled when the clock causes the callback to be called on the right
CPU, which is why xennet still run, but slowly.
Change event_set_handler() to do a EVTCHNOP_bind_vcpu if requested to,
and make sure we don't do it for IPIs and VIRQs (for theses, the op fails).
returned by DIOCGPARTINFO if it's bigger than DEV_BSIZE and less
than MAXBSIZE (MAXPHYS)
fixes panic "buf mem pool index 8" in buf_mempoolidx() when the
disklabel contains bsize 128KB and something reads the block device -
buffer cache can't allocate bufs bigger than MAXPHYS
The primary issue was that in revision 1.79 a check was added in the
nd6_defrouter_select() search loop to ignore the entry if RA processing
is enabled on its interface. In practice this results in all entries
being ignored.
This fix reverses the condition, so that an entry is ignored when RA
processing is NOT enabled on its interface. Further, the entry is
only ignored for being selected as the default router. The currently
installed router must be identified regardless of the (current) status
of its interface, so that we can delete the route before installing a
new one.
I also added error logging when adding or deleting a route fails. This
should help the administrator (or kernel developer) in noticing possible
problems.
Finally, if deleting a route fails, the corresponding default route
entry no longer has its "installed" flag cleared, so that deletion will
be retried. At a minimum, this will cause repeated messages about the
failed deletion as opposed to only getting repeated messages about the
installation of a new default route failing.
Fixes PR kern/55091 and also PR bin/54997 as far as the behaviour
observed with ndp(8).
