| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
ass-backwards.
afaik this was found by the LLVM CLang static analyser.
ok ariane@ a couple of days ago.
|
|
(just a noop since that doesn't matter in userland).
Pointed out by a couple of people, thanks.
|
|
OK millert@, deraadt@
|
|
Add a note that the regress depends on the "family" keyword in resolv.conf
OK millert@, deraadt@
|
|
|
|
|
|
while here, use lowercase letters for "usage:".
|
|
changed with a sysctl, so note it in sysctl.conf. v6 needs further
testing following discussions on the tech mailing list; rainer@ points
out possible interactions with neighbour discovery which need to be
investigated first.
"go ahead on the v4 part" deraadt@
|
|
question if dmesg changes are detected. The password reading
routines are not subject to these changes at this point.
ok deraadt@, krw@
|
|
first 30 do nothing. perhaps there are other codecs with such
amps? (ab)use some reserved bits in the amplifier capabilities
parameter to store the first volume step that actually changes the
volume. problem reported and patch tested by LEVAI Daniel.
|
|
reported and patch tested by Bryan Chapman. according to FreeBSD,
this might be needed for other MacBookPro models but no one else has
told me their MacBookPro doesn't work.
|
|
as suggested by mk@. Shortened verbiage allows us to bring back 'L'
as a way to list the alternate layouts, as pointed out by Andr?s
on tech@. On some keyboards finding the '?' can be a challenge
before the layout is set.
ok deraadt@
|
|
My
bios0: ASUSTeK Computer INC. P5K-E
cpu0: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz, 2405.74 MHz
cpu1: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz, 2405.46 MHz
cpu2: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz, 2405.46 MHz
cpu3: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz, 2405.46 MHz
can't boot with this in. It always hangs somewhere in fsck'ing if
any, or between netstart and local daemons if no fsck'ing. Also
fubars theo's real amd machine.
Much more testing needed for this.
|
|
help worsen the interrupt race that dale is trying to fix. He'll get that
fixed, but for now, we can try to run macppc in the most reliable fashion.
|
|
|
|
and it is pretty critical so commiting it now. Any more fallout from
the code 'simplication'?
|
|
this might need to be revisted later if its clear that there are machines
which only come up with a single state but more may appear after a PPC
change but for now we will just not initilize on systems with a single
state a boot. Solves a divide by zero panic when using the PDC diff on
broken hardware.
ok marco@, krw@
|
|
|
|
|
|
to u_int32_t to do integer math with (in a situation where that is legit)
ok otto millert
|
|
prompted by a fix from Warner Losh, freebsd -r193625,
but i chose a different fix;
help/ok otto
|
|
ok kili@
cvs: ----------------------------------------------------------------------
|
|
|
|
as well, reminded by miod@
|
|
ok oga@
|
|
Make the imsg protocol network-safe.
it might be network safe, but half the imsg based daemons on my firewalls
dont run anymore.
|
|
but our local copy proto that we very carefully set beforehands. skw
being NULL is perfectly valid there.
|
|
found by sthen and fixed, all other callers of these macros checked by both
of us
|
|
steps found with the recent pfvar.h commit to check address families.
from & commit req by henning.
|
|
by backing out the macro fix. something must rely on the broken behaviour
|
|
|
|
was added in 2001. yes i got bitten by inet6 shit again.
in the ANEQ case, if af == AF_INET, (a)->addr32[0] != (b)->addr32[0]
is false when the adresses ARE equal. now it goes right in the
intended-for-v6 case and starts to compare the other addr32 fields -
in the v4 case I have garbage in them, so it reports all v4 as different
when they are in fact the same. fix by adding explicit af == INET6 test
before going on to compare the rest.
found the really hard way (many hours wasted, thought the bug was in my
new code) by me. ok sthen markus claudio
|
|
|
|
|
|
|
|
|
|
normally as long as we define __need_process and use a local
definition of struct proclist.
|
|
|
|
caused the PIC to not be initialized on resume, which caused much
badness - things attached to the ISA bus weren't getting any
interupts (for example, keyboards).
Also move around some of the lapic reinit code to handle some clock
initialization bits we weren't doing before.
Worked out by deraadt and myself.
ok deraadt@
|
|
These values were used to eventually pass ranges to uvm_pglistalloc(),
which has been fixed to correctly skip no-memory ranges a lot of time ago;
however mvme68k would still use the computed range and osiop would no
longer attach; this repairs it.
|
|
used.
|
|
|
|
no binary change and consistent with other usage of the macro.
|
|
|
|
|
|
|
|
|
|
|
