in /etc/fstab. We do support passing special options on a per
filesystem type basis, like `-u UID -g GID' for mount_msdosfs, but
the syntax of these options in fstab is non-obvious and a lot of
users have asked about it.
PR: docs/128816
Submitted by: Roland Smith, rsmith at xs4all dot nl
MFC after: 2 days
the following syntax in the kernel config.
makeoptions MODULES_OVERRIDE=foo
makeoptions MODULES_OVERRIDE+=bar
makeoptions MODULES_OVERRIDE+=baz
Bump config minor version to 600007.
mnt_lock is before lock of any vnode on the mp, it uses LK_NOWAIT. Since
MNTK_UNMOUNT may be transient, pdp lock is dropped when vfs_busy()
failed, and operation is retried after some time. This way, ffs_vget()
is not called on the mp that may be in the process of being destroyed by
unmount.
Check for the VI_DOOMED flag on pdp after its lock is reacquired, to
better detect some situations where directory containing ".."
entry is removed during the lookup.
Reviewed by: tegge, attilio (previous version)
Tested by: pho
MFC after: 1 month
of the ABI of the currently executing image. Change some places to test
the flags instead of explicit comparing with address of known sysentvec
structures to determine ABI features.
Discussed with: dchagin, imp, jhb, peter
- invert sense of hw.cxgb.singleq tunable to hw.cxgb.multiq
- don't wake up transmitting thread by default
- add per tx queue ifaltq to handle ALTQ
- remove several unused functions in cxgb_multiq.c
- add several sysctls: multiq_tx_enable, coalesce_tx_enable,
and wakeup_tx_thread
- this obsoletes the hw.cxgb.snd_queue_len as ifq is replaced
by a buf_ring
and ifnet functions
- add memory barriers to <machine/atomic.h>
- update drivers to only conditionally define their own
- add lockless producer / consumer ring buffer
- remove ring buffer implementation from cxgb and update its callers
- add if_transmit(struct ifnet *ifp, struct mbuf *m) to ifnet to
allow drivers to efficiently manage multiple hardware queues
(i.e. not serialize all packets through one ifq)
- expose if_qflush to allow drivers to flush any driver managed queues
This work was supported by Bitgravity Inc. and Chelsio Inc.
1) Fix a bug in dealing with the Alerus 1006 PHY which prevented the
device from ever coming back up once it had been set to down.
2) Add a kernel tunable (hw.cxgb.snd_queue_len) which makes it possible
to give the device more than IFQ_MAXLEN entries in its send queue. The
default remains 50.
3) Add code to place the card'd identification and serial number into
its description (%desc) so that users can tell which card they have
installed.
and XMITS has to be basically done in the same manner as for
the Sabres, i.e. only for devices behind PCI-PCI-bridges and
after a PIO read on the far side of the farest PCI-PCI-bridge.
Given that the Tomatillo documentation mentions no difference
to the Schizo bridges in this regard and this is also still
part of the procedure described Schizo documentation this
seems about right so adjust accordingly (the unconditional
CDMA flushing/syncing previously done was based on how Linux
behaves).
- Implement CDMA flushing/syncing for Schizo version >= 5,
which requires the workaround described in Schizo Errata I-23.
According to Schizo Errata I-13 it's just unusable with
version < 5 though. [1]
- Don't register the Schizo streaming buffer for now until it's
usage is sorted out according to the erratas.
- Register our interrupt filters with the revived INTR_FAST so
they these interrupts can even interrupt filters of device
drivers as necessary.
- Remove the comment regarding lack of newbus'ified bus_dma(9)
as being able to associate a DMA tag with a device would
allow to implement CDMA flushing/syncing in bus_dmamap_sync(9)
but that would totally kill performance. Given that for devices
not behind a PCI-PCI bridge the host-to-PCI bridges also only
do CDMA flushing/syncing based on interrupts there's no
additional disadvantage for polling(4) callbacks in the case
schizo(4) has to do the CDMA flushing/syncing but rather a
general problem.
Reported by: Michael Moll [1]
above) exhibits some misbehaviours on machines with AMD64 CPUs,
which at least in some cases I have tracked down to a heap overflow.
It is unclear whether it depends on the CPU or on the pxe bios
itself which may use more memory on AMD machines.
Noticeably a pxeboot compiled from 6.x sources works fine on all
machines I have tried so far, while a pxeboot compiled from 7.x
sources does not.
This patch is a first step in reducing the amount of memory used
while processing the configuration files read by the loader at boot
(some of them are quite large, 1700+ lines), and it does so by:
+ moving a buffer to static memory instead of allocating in the heap;
+ skipping empty lines;
+ reducing the amount of memory used for line descriptors;
Unfortunately there are several changes between 6.x and above,
affecting the compiler, the loader code itself, and libstand,
and it is not so straightforward to
These changes fix the behaviour on one motherboard with a
single-core AMD cpu, but are still not enough e.g on an Asus
M2N-VM (with a dual-core CPU).
I need to investigate the problem a bit more before figuring
out what should be committed to RELENG_7
PR: kern/118222
assumed it had to toggle between attribute and common memory in the
cards. The kernel is supposed to cope with that automatically and
give us a tuple list. However, there's a number of details of how
that happens that's currently, ummm, magical and/or not implemented
for 16-bit PC Cards that have CIS_LONGLINK_C tuples in them (eg, mix
both attribute memory and common memory). Also, CIS_LOGNLINK_A
entries might not be handled completely correctly either, since there
can be gaps in the attribute vs common stuff.
All this will need to be corrected in the kernel. Once it is
corrected, dumpcis can be made even simpler in some ways, a little
more complicated in others once an API for presentation of CIS to
userland in these weird cases is settled upon.
