Age | Commit message (Collapse) | Author |
|
not make these drivers spew millions of lines of output.
spotted as missing by miod
|
|
|
|
not make these drivers spew millions of lines of output.
ok krw
|
|
|
|
|
|
ok henning@
|
|
ok marco@, deraadt@
|
|
interrupts. It is irreleveant, confuses people and the information is
available in pcidump(8) output anyway.
ok oga@, jsg@, deraadt@
|
|
|
|
From Laurence Tratt.
ok claudio@ deraadt@
|
|
after more than a year of grovelling emails shows further effort
is pointless.
ok matthew@ dlg@
|
|
|
|
feedback & ok guenther@, matthew@
|
|
|
|
|
|
arithmetic add.
|
|
|
|
with memory beyond 4GB physical a chance to run. For some reason IP27 was
already correct.
|
|
first eight arguments saved, due to the layout of the call frame.
ok kettenis@
|
|
ok kettenis@
|
|
port init.
problem reported by RD Thrush in PR6590
|
|
change. It seems to have unexpected side effects, especially on MP systems,
and drahn@ disagrees with the way this change has been done and think there
is a better way to solve the original problem of msleep() fiddling with
mutex internals.
|
|
atascsi goes and throws away all the ccbs that the disk wont use, including
the reserved one.
this makes ahci reserve its own ccb.
light testing by krw@ without regression.
|
|
|
|
|
|
|
|
intrstat on arc may have other status bits set which are masked as
interrupt cause and not handled by our driver. So the intrstat ==
0 check does not work reliably. It is better to do use a variable
that is set to 1 when work is done and the cause is cleared.
This makes arc(4) behave on systems where interrupts are shared.
OK deraadt@ dlg@
|
|
correct fix applied to 3 similar drivers
ok chl
|
|
generic puc(4) device.
ok deraadt@
|
|
when leaving. when you're handling an interrupt it is masked.
whacking the chip is work for no gain.
diff from chris@
tested by marco@
ok by me :)
|
|
This one works. For me at least.
Botch spotted by matthew@.
ok matthew@ dlg@
|
|
|
|
|
|
|
|
the USB serial number so as to limit the overall devid to just 20
characters.
"Lovely!" deraadt@
|
|
"no objection" drahn@
|
|
ok claudio@
|
|
ok kettenis@
|
|
Found by LLVM/Clang Static Analyzer.
ok marco@ krw@
|
|
Found by LLVM/Clang Static Analyzer.
ok henning@
|
|
Found by LLVM/Clang Static Analyzer.
ok miod@ jsg@
|
|
Found by LLVM/Clang Static Analyzer.
ok miod@ krw@
|
|
revisions; despite what the ``official'' (yet unpublished, confidential
proprietary, will cause a tree to fall on your house if you quote it, etc)
errata says, disabling data decoupling is not enough to workaround its
malfunction in processor revisions 5.x.
Enough missing-SFU instructions (each causing a `disabled SFU' trap) in a
tight loop will eventually (but quickly) trigger the (unrecoverable, not even
by NMI) processor hang.
Of course, most such instructions are not privileged, and can be easily issued
by an evil userland process; crashme happens to be a good example of this, when
invoked with the proper settings (which are left as an exercise to the reader).
Now, can I have my hair back? Come on! Please... pretty please... with sugar on
top... people are looking at my head, you know.
|
|
|
|
ok deraadt@, miod@
|
|
|
|
since its an int, not a long.
ok deraadt@
|
|
confusing because both addresses and broadcast addresses are put
into the tree.
there are two types of local address lookup. the first is when the
socket layer wants a local address, the second is in ip_input when
the kernel is figuring out the packet is for it to process or
forward.
ip_input considers local addresses and broadcast addresses as local,
however, the handling of broadcast addresses is different depending
on whether ip_directedbcast is set. if if ip_directbcast is unset
then a packet coming in on any interface to any of the systems
broadcast addresses is considered local, otherwise the broadcast
packet must exist on the interface it was received on.
the code also needs to consider classful broadcast addresses so we
can continue some legacy applications (eg, netbooting old sparcs
that use rarp and bootparam requests to classful broadcast addresses
as per PR6382). this diff maintains that support, but restricts it
to packets that are broadcast on the link layer (eg, ethernet
broadcasted packets), and it only looks up addresses on the local
interface. we now only support classful broadcast addresses on local
interfaces to avoid weird side effects with packets routed to us.
the ip4 socket layer does lookups for local addresses with a wrapper
around the global address tree that rejects matches against broadcast
addresses. we now no longer support bind sockets to broadcast
addresses, no matter what the value of ip_directedbcast is.
ok henning@
testing (and possibly ok) claudio@
|
|
from a USB serial number, as recommended by the umass spec.
ok dlg@
|
|
until they're zombies and then send them signals (for intr mounts). Until
that is untangled, the sigacts change is unsafe. sthen@ was the victim
for this one
|