- Fix a missing back pointer assignment in struct prefix to struct rainfo
when addr="" is specified. This caused SIGSEGV.
- Insert a prefix element to a tail queue after setting parameters.
When user wants have specific alignment - do what user wants.
Use stripesize as alignment value in case, when some of gpart's
arguments are ommitted for automatic calculation.
Suggested by: mav
For the AR5211/AR5212, this is apparently a one byte pulse duration
counter value. It is only coded up here for the AR5212 as I don't have
any AR5211-series hardware to test it on.
This information was extracted from the Madwifi DFS branch along with
some local additions.
Please note - all this does is extract out the radar event duration,
it in no way reflects the presence of a radar. Further code is needed
to take a set of radar events and filter them to extract out correct
radar pulse trains (and ignore other events.)
For further information, please see:
http://wiki.freebsd.org/dev/ath_hal%284%29/RadarDetection
This includes references to the relevant patents which describe what
is going on.
Obtained from: Madwifi
This is intended to fix the bug where cpu mask objects are
capped to 32. MAXCPU, then, can now arbitrarely bumped to whatever
value. Anyway, as long as several structures in the kernel are
statically allocated and sized as MAXCPU, it is suggested to keep it
as low as possible for the time being.
Technical notes on this commit itself:
- More functions to handle with cpuset_t objects are introduced.
The most notable are cpusetobj_ffs() (which calculates a ffs(3)
for a cpuset_t object), cpusetobj_strprint() (which prepares a string
representing a cpuset_t object) and cpusetobj_strscan() (which
creates a valid cpuset_t starting from a string representation).
- pc_cpumask and pc_other_cpus are target to be removed soon.
With the moving from cpumask_t to cpuset_t they are now inefficient
and not really useful. Anyway, for the time being, please note that
access to pcpu datas is protected by sched_pin() in order to avoid
migrating the CPU while reading more than one (possible) word
- Please note that size of cpuset_t objects may differ between kernel
and userland. While this is not directly related to the patch itself,
it is good to understand that concept and possibly use the patch
as a reference on how to deal with cpuset_t objects in userland, when
accessing kernland members.
- KTR_CPUMASK is changed and now is represented through a string, to be
set as the example reported in NOTES.
Please additively note that no MAXCPU is bumped in this patch, but
private testing has been done until to MAXCPU=128 on a real 8x8x2(htt)
machine (amd64).
Please note that the FreeBSD version is not yet bumped because of
the upcoming pcpu changes. However, note that this patch is not
targeted for MFC.
People to thank for the time spent on this patch:
- sbruno, pluknet and Nicholas Esborn (nick AT desert DOT net) tested
several revision of the patches and really helped in improving
stability of this work.
- marius fixed several bugs in the sparc64 implementation and reviewed
patches related to ktr.
- jeff and jhb discussed the basic approach followed.
- kib and marcel made targeted review on some specific part of the
patch.
- marius, art, nwhitehorn and andreast reviewed MD specific part of
the patch.
- marius, andreast, gonzo, nwhitehorn and jceel tested MD specific
implementations of the patch.
- Other people have made contributions on other patches that have been
already committed and have been listed separately.
Companies that should be mentioned for having participated at several
degrees:
- Yahoo! for having offered the machines used for testing on big
count of CPUs.
- The FreeBSD Foundation for having sponsored my devsummit attendance,
which has been instrumental.
- Sandvine for having offered offices and infrastructure during
development.
(I really hope I didn't forget anyone, if it happened I apologize in
advance).
Make a behaviour of the libalias based in-kernel NAT a bit closer to
how natd(8) does work. natd(8) drops packets only when libalias returns
PKT_ALIAS_IGNORED and "deny_incoming" option is set, but ipfw_nat
always did drop packets that were not aliased, even if they should
not be aliased and just are going through.
Also add SCTP support: mark response packets to skip firewall processing.
MFC after: 1 month
how natd(8) does work. natd(8) drops packets only when libalias returns
PKT_ALIAS_IGNORED and "deny_incoming" option is set, but ipfw_nat
always did drop packets that were not aliased, even if they should
not be aliased and just are going through.
PR: kern/122109, kern/129093, kern/157379
Submitted by: Alexander V. Chernikov (previous version)
MFC after: 1 month
Many thanks to Tino <tinotom@gmail.com> for drawing my attention to
this, for doing a lot of testing and providing great feedback.
Many thanks to AMD for continuing to release public specifications for
their chipsets.
PR: kern/157568
Tested by: Tino <tinotom@gmail.com>
MFC after: 1 week
Otherwise, p_bufr is set to garbage on the stack, and if that garbage
happens to be non-NULL, and the TOLOG or TOCONS flag is set, putbuf()
will get called and attempt to fill the non-existent buffer.
This is really only relevant for tprintf() (and only when the priority is
not -1), but set it in uprintf() and ttyprintf() for completeness.
The next step, to avoid log buffer scrambling, would be to add the
PRINTF_BUFR_SIZE code to tprintf(), but this should prevent panics.
Submitted by: rmacklem
Found by: pho
for it. Do not not expect a developer to call doadump(). Calling
doadump does not necessarily work when it's declared static. Nor
does it necessarily do what was intended in the context of text
dumps. The dump command always creates a core dump.
Move printing of error messages from doadump to the dump command,
now that we don't have to worry about being called from DDB.
points are fixed addresses and (U)EFI CSM specification also mandated that.
Unfortunately, (U)EFI CSM specification does not specifically mention this
is to call service routine via interrupt vector table or to jump directly
to the entry point. As a result, some CSM seems to install two routines
and acts differently, depending on how it was executed, unfortunately.
When INT 15h is used, it calls a function pointer (which is probably a UEFI
service function). When it jumps directly to the entry point, it executes
a simple and traditional INT 15h service routine. Therefore, actually there
are two possible fixes, i. e., this fix or jumping directly to the fixed
entry point. However, we chose this fix because a) keyboard typematic
support via BIOS is becoming extremely rarer and b) we cannot support random
service routine installed by a firmware or a boot loader. This should fix
Lenovo X220 laptop, specifically.
Reviewed by: delphij
MFC after: 3 days
Rather than including lock.h in in_pcbgroup.c in right order, fix it
for all consumers of in_pcb.h by further header file pollution under
#ifdef KERNEL.
Reported by: Pan Tsu (inyaoo gmail.com)
High-speed USB HUB by resetting the transaction translator (TT)
before trying re-enumeration. Also when clear-stall fails multiple times
try a re-enumeration.
Suggested by: Trevor Blackwell
MFC after: 14 days
the '-c' argument is passed to the shell, not to su(1), which would
indicate the login class.
'su -m <user> -c <command>'
Submitted by: Warren Block <wblock@wonkity.com> (followup to 157078)
MFC after: 5 days
o cpu_idle_hook is expected to be called with interrupts
disabled and re-enables interrupts on return.
o sync with x86: don't idle when the CPU has runnable tasks
o have callers of ia64_call_pal_static() disable interrupts
and re-enable interrupts.
o add, but compile-out, support for idle mode. This will be
enabled at some later time, after proper testing.
While implementing a tool to import lastlog entries into utmpx, I
noticed lastlogin doesn't allow custom database files to be opened. Add
a -f switch to support this. Also, add -r and -t similar to ls(1),
ruptime(1), etc. where you can sort entries by timestamp and reverse
them. This allows you to spot active/idle users more easily.
This regression was introduced in r213323.
There are probably no Intel cpus that support amd64 mode, but do not
support cpuid level 4, but it's better to keep i386 and amd64 versions
of this code in sync.
Discovered by: pho
Tested by: pho
MFC after: 2 weeks
the recent changes to track BAR state explicitly. The code would now
attempt to add the same BAR twice in this case. Instead, change this so
that it recognizes this case and only adds it once and do not delete the
BAR outright after parsing the CIS.
Tested by: bschmidt
chnage is different to the one suggested in the PR to try to avoid
cluttering the man page too much.
PR: docs/154494
Submitted by: kilian <kilian.klimek googlemail.com>
MFC after: 1 week
