while on i386 we have MAX_BPAGES=512. Implement this difference via
'#ifdef __i386__'.
With this commit, the i386 and amd64 busdma_machdep.c files become
identical; they will soon be replaced by a single file under sys/x86.
no-op currently, since FreeBSD/amd64 doesn't have (paravirtualized) Xen
support, but if/when that support is ever added we'll want this, and
until then it's harmless.
snmp_vacm modules and minimal user/view configurations needed to for
the modules to work properly.
Sponsored by: The FreeBSD Foundation
Reviewed by: philip@ (mostly)
Approved by: philip@
re-arming the watchdog timeout.
Sponsored by: Sandvine Incorporated
Submitted by: Mark Johnston <mjohnston at sandvine dot com>
Reviewed by: des
MFC after: 10 days
Sponsored by: The FreeBSD Foundation (the SNMPv3 bits), Google Summer of Code 2005
Reviewed by: philip@ (mostly), bz@ (earlier version based on p4 ch124545)
Approved by: philip@
if creating a mirror by attaching a new vdev to a root pool.
Reported by: James R. Van Artsdalen (on freebsd-fs@freebsd.org)
Approved by: delphij (mentor)
MFC after: 3 days
AX88772 controllers. ASIX added a new feature for AX88178/AX88772
controllers which allows combining multiple TX frames into a single
big frame. This was to overcome one of USB limitation where it
can't generate more than 8k interrupts/sec which in turn means USB
ethernet controllers can not send more than 8k packets per second.
Using ASIX's feature greatly enhanced TX performance(more than 3~4
times) compared to 7.x driver. However it seems r184610 removed
boundary checking for buffered frames which in turn caused
instability issues under certain conditions. In addition, using
ASIX's feature triggered another issue which made USB controller
hang under certain conditions. Restarting ethernet controller
didn't help under this hang condition and unplugging and replugging
the controller was the only solution. I believe there is a silicon
bug in TX frame combining feature on AX88178/AX88772 controllers.
To address these issues, reintroduce the boundary checking for both
AX88178 and AX88772 after copying a frame to USB buffer and do not
use ASIX's multiple frame combining feature. Instead, use USB
controller's multi-frame transmit capability to enhance TX
performance as suggested by Hans[1].
This should fix a long standing axe(4) instability issues reported
on AX88772 and AX88178 controllers. While I'm here remove
unnecessary TX frame length check since upper stack always
guarantee the size of a frame to be less than MCLBYTES.
Special thanks to Derrick Brashear who tried numerous patches
during last 4 months and waited real fix with patience. Without
this enthusiastic support, patience and H/W donation I couldn't fix
it since I was not able to trigger the issue on my box.
Suggested by: hselasky [1]
Tested by: Derrick Brashear (shadow <> gmail dot com>
H/W donated by: Derrick Brashear (shadow <> gmail dot com>
PR: usb/140883
isn't configurable in a meaningful way. This is for ifconfig(8) or
other tools not to change code whenever IFT_USB-like interfaces are
registered at the interface list.
Reviewed by: brooks
No objections: gavin, jkim
looking to see if there is an existing IRQ resource for a given IRQ
provided by the BIOS and using that RID if so. Otherwise, allocate a new
RID for the new IRQ.
Reviewed by: mav (a while ago)
In particular, this check avoids a warning when
extracting directory entries from certain GNU tar
archives that store directory contents.
MFC after: 3 days
detected ashift does not support this. With this change, pools
created while stripesize=512 could not be imported when stripesize
becomes larger (on the same drive).
Noticed by: pjd
In exec_linux_setregs(), use locally cached pointer to pcb to set
pcb_full_iret.
In set_regs(), note that full return is needed when code that sets
segment registers is enabled.
MFC after: 1 week
The dealock was caused in the following way:
- thread T1 on CPU C1 holds a spin mutex, IPIs CPU C2 and waits for the
IPI to be handled
- C2 executes timer interrupt filter, thus has interrupts disabled, and
gets blocked on the spin mutex held by T1
The problem seems to have been introduced by simplifications made to
OpenSolaris code during porting.
The problem is fixed by reorganizing the code to more closely resemble
the upstream version. Interrupt filter (cyclic_fire) now doesn't
acquire any locks, all per-CPU data accesses are performed on a
target CPU with preemption and interrupts disabled thus precluding
concurrent access to the data.
cyp_mtx spin mutex is used to disable preemtion and interrupts; it's not
used for classical mutual exclusion, because xcall already serializes
calls to a CPU. It's an emulation of OpenSolaris
cyb_set_level(CY_HIGH_LEVEL) call, the spin mutexes could probably be
reduced to just a spinlock_enter()/_exit() pair.
Diff with upstream version is now reduced by ~500 lines, however it still
remains quite large - many things that are not needed (at the moment) or
are irrelevant on FreeBSD were simply ripped out during porting.
Examples of such things:
- support for CPU onlining/offlining
- support for suspend/resume
- support for running callouts at soft interrupt levels
- support for callout rebinding from CPU to CPU
- support for CPU partitions
Tested by: Artem Belevich <fbsdlist@src.cx>
MFC after: 3 weeks
X-MFC with: r216252
The code to translate the internal representation to text did not know about
various additions to the internal representation since the original ash and
therefore wrote binary stuff to the terminal.
The code is used in the jobs command and similar output.
Note that the output is far from complete and mostly serves for recognition
purposes.
on release CDs and so will normally fail.
installCommit() returns a DITEM_ value, not a Boolean.
distExtractAll() returns a Boolean, not a DITEM_ value.
Reported by: kensmith
MFC after: 3 days
max_request_segments * PAGE_SIZE if the I/O is page-aligned; the
largest I/O we can guarantee will work is PAGE_SIZE less than that.
This unbreaks 'diskinfo -t'.
and set *procp to NULL in all cases. Previously, it was not being set
in the ERESTART case. This is effectively no-op, since its value is
ignored by callers in the error case.
Reviewed by: kib@
as an association ID is set any scan is supposed to be a background scan.
This implies that the firmware will switch back to the associated channel
after a certain threshold, though, we are not notified about that. We
currently catch this case by a timer which will reset the firmware after
a 'scan timeout', though, upper layers are not notified about that and
will simply hang until manual intervention. Fix this by resetting the
firmware's knowledge about any association on RUN -> ASSOC and
!INIT -> SCAN transitions.
Tested by: Zhihao Yuan <lichray at gmail.com>
MFC after: 1 week
