clean-up, and mention that it is "fully qualified and sanctioned by
Adaptec".
Requested by: scottl (the last part, that is)
Approved by: re (implicitly)
likely looking rate calculation.
Install interrupt handler before calling ich_init as the initialization
occasionally generates spurious interrupts.
These changes are derived from cg's work in progress version of this
driver.
camcontrol.
This enables rescanning all busses or resetting all busses in a system.
The current implementation is not the ideal way to do it -- the ideal way
to do it would be for the transport layer to handle wildcarded busses on
bus rescan and reset operations. The current implementation enumerates all
the busses and sends a rescan or reset CCB individually. Handling this
behavior in the transport layer will happen later.
Reviewed by: imp
Tested by: joerg
MFC after: 1 week
: 2002-01-17 Ruslan Ermilov <ru@FreeBSD.org>
:
: * tmac/doc.common: Initialize %I register for the %I macro to
: avoid (harmless) warning.
: * tmac/doc.tmac (Bd): There is no reason to enforce -compact
: when in the SYNOPSIS section.
socket so that routing daemons and other interested parties
know when an interface is attached/detached.
PR: kern/33747
Obtained from: NetBSD
MFC after: 2 weeks
db_machdep.h to fix the link failure (multiple definitions)
caused by disabling the emission of common symbols. As a result,
there were no definitions at all. While here, remove useless
declarations.
because the buffers we use could end up spanning a 64k boundary.
Unfortunately it causes too much bloat (228 -> 72 bytes free) to
just reinstate the old malloc() function.
Instead, define a structure that contains all 4 buffers which must
not cross 64k boundaries. We allocate a 64k-aligned instance in
main() using the magic that was in the old boot2 malloc() function.
This brings the free space down to 168 bytes, but that is still
better than it was before revision 1.35 (136 bytes).
Reported by: Mike Brancato <funnyguy@digitalsmackdown.net>
Pointy-hat to: iedowse
We now do it as a "camcontrol rescan all" which is something ken
promised to implement; for the time being it's not worse than the old
"camcontrol rescan $device" which ended up in something like
"camcontrol rescan aic1". Currently, camcontrol misinterprets the
third non-numeric arg as number 0, and rescans bus 0, which is about
the best we could get at this time.
Approved by: imp
MFC after: 1 week
at insert time. When asking gibbs for approval for an MFC, this was
his reply:
1) It leaks memory if it can't allocate a path.
2) It defers allocation of aic->path until the call to scan the
bus. This means the path may be NULL when an interrupt occurs
prior to the call to scan the bus (stray bus reset for instance),
which will lead to a panic.
3) The driver in current doesn't recover from the failure to allocate
aic->path. The driver doesn't check during normal operation if
the path is NULL, so again a panic will result.
4) aic_cam_rescan calls malloc with M_WAITOK. aic_cam_rescan is called
from attach where it isn't necessarily safe to sleep.
5) And most importantly, it co-opts the xpt_periph from the driver level.
This was never part of the design (xpt_periph used to be static). Making
a call of this type may completely confuse the XPT if other XPT operations
are ongoing.
In the long term, Justin and Warner agreed to implement solution where
CAM itself will initiate the bus rescan if a new bus is added. For
the time being (and in particular in light of the upcoming 4.5
release), we now have camcontrol available on the boot floppy, and can
have pccardd initiate the rescan through it.
This change should/could be merged into other arch's release build
areas (PC98, Alpha), but since i cannot test a "make release" there, i
won't do this myself.
MFC after: 1 week
variable RELEASE_BUILD_FIXIT is defined, a camcontrol binary will be
built that only knows the "rescan" and "reset" subcommands. The
resulting code is small enough to still fit onto the boot floppy.
Reviewed by: ken
MFC after: 1 week
previous commit, it should always print due to lack of {} around the
second line in the if statement. The message should likely say
something more like "There's no hardware responding at this IRQ.
Device not present (or disbaled)," but that is too long. We generally
don't give elementary advise in device driver messages anyway. Be
that as it may, the problem with it printing all the time should be
corrected.
which caused incomplete snapshots to be taken. When background
fsck would run on these snapshots, the result would be files
being incorrectly released which would subsequently panic the
kernel with ``handle_workitem_freefile: inodedep survived'',
``handle_written_inodeblock: live inodedep'', and
``handle_workitem_remove: lost inodedep'' errors.
