| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
of an nmount()-based mount program for UFS.
Now that mount(8) calls nmount() directly for mounting UFS filesystems,
they are unnecessary.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
directly. We need to copyin() the strings in the iovec before
we can strcmp() them. Also, when we want to send the errmsg back
to userspace, we need to copyout()/copystr() the string.
Add a small helper function vfs_getopt_pos() which takes in the
name of an option, and returns the array index of the name in the iovec,
or -1 if not found. This allows us to locate an option in
the iovec without actually manipulating the iovec members. directly via
strcmp().
Noticed by: kris on sparc64
|
| |
|
| |
|
|
|
|
|
|
|
| |
These options are read from fstab by quotacheck(8), but are not
valid mount options that need to be passed down the the filesystem.
Noticed by: maxim
|
|
|
|
|
|
|
|
| |
in rev1.37.
- Fixing a core dump inside build_iovec_argf by providing a !NULL format
string to vsnprintf(3).
Reviewed by: rodrigc
|
|
|
|
|
|
|
|
|
|
|
| |
- Add locked variants of start, init, and ifmedia_upd.
- Add a mutex to the softc and remove spl calls.
- Use callout(9) rather than timeout(9).
- Setup interrupt handler last in attach.
- Use M_ZERO rather than bzero.
MFC after: 1 week
Tested by: wpaul
|
|
|
|
| |
Pointy hat to: jhb (2)
|
| |
|
|
|
|
| |
Obtained from: NetBSD
|
| |
|
|
|
|
| |
real memmove() implementation and use that instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- Improve panic message if we fail to read the PCI bus number from a bridge
device.
- Don't try to lookup a BIOS IRQ for a link unless the link is routed via
an ISA IRQ since BIOSen currently only route PCI link devices via ISA
IRQs.
Tested by: Mathieu Prevot bsdhack at club-internet dot fr
MFC after: 1 week
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a minor interface change. The function is renamed from
__kernel_tanf() to __kernel_tandf() so that misues of it will cause
link errors and not crashes.
This version is a routine translation with no special optimizations
for accuracy or efficiency. It gives an unimportant increase in
accuracy, from ~0.9 ulps to 0.5285 ulps. Almost all of the error is
from the minimax polynomial (~0.03 ulps and the final rounding step
(< 0.5 ulps). It gives strange differences in efficiency in the -5
to +10% range, with -O1 fairly consistently becoming faster and -O2
slower on AXP and A64 with gcc-3.3 and gcc-3.4.
|
| |
|
|
|
|
|
| |
Prodded by: Mark Andrews <Mark_Andrews AT isc DOT org>
MFC after: 2 days
|
| |
|
|
|
|
|
|
|
|
| |
but not provide a panic(9) implementation. Thus, enable the sanity
checks under INVARIANTS only if _KERNEL is also defined.
Submitted by: jmallett
Approved by: rwatson (mentor)
|
|
|
|
|
| |
with a 24-bit fraction, so we don't need a loop to split it into up to
3 terms with 24-bit fractions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
arg to __kernel_rem_pio2() gives 53-bit (double) precision, not single
precision and/or the array dimension like I thought. prec == 2 is
used in e_rem_pio2.c for double precision although it is documented
to be for 64-bit (extended) precision, and I just reduced it by 1
thinking that this would give the value suitable for 24-bit (float)
precision. Reducing it 1 more to the documented value for float
precision doesn't actually work (it gives errors of ~0.75 ulps in the
reduced arg, but errors of much less than 0.5 ulps are needed; the bug
seems to be in kernel_rem_pio2.c). Keep using a value 1 larger than
the documented value but supply an array large enough hold the extra
unused result from this.
The bug can also be fixed quickly by increasing init_jk[0] in
k_rem_pio2.c from 2 to 3. This gives behaviour identical to using
prec == 1 except it doesn't create the extra result. It isn't clear
how the precision bug affects higher precisions. 113-bit (quad) is
the largest precision, so there is no way to use a large precision
to fix it.
|
|
|
|
|
|
|
|
| |
Instead, re-evaluate _BIF only when we get a notify and use the cached
results. We also still evaluate _BIF once on boot. Also, optimize the
init loop a little by only querying for a particular info if it's not valid.
MFC after: 2 days
|
|
|
|
|
|
|
| |
service name instead of channel number with -c command option. Supported
service names are: DUN (Dial-Up Networking), FAX (Fax) and SP (Serial Port).
MFC after: 1 week
|
|
|
|
| |
functional change.
|
| |
|
|
|
|
| |
them out of machine/smptests.h.
|
| |
|
|
|
|
|
|
|
| |
during SMP startup. We haven't had any issues with starting up the APs
on i386 in quite a while now which is all this code is really useful for.
If someone ever does really need it they can always dig it up out of the
attic.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
INO) for incorrect interrupt map entries on E250 machines. These
incorrect entries caused the INO of the on-board HME to be also
assigned to the second on-board NS16550 and to the on-board printer
port controller. Further down the road caused hme(4) to fail to attach
to the on-board HME in FreeBSD 5 and 6 as INTR_FAST and non-INTR_FAST
handlers can't share the same IRQ there (it's unknown what whould
happen in -CURRENT now that INTR_FAST and non-INTR_FAST handlers can
share an IRQ but I'd expect funny problems with uart(4)).
- Make sure there are exactly 4 PCI ranges instead of just checking
that the bridge has a 'ranges' property in the OFW device tree at all.
Besides the fact that currently the 64bit memory range isn't used by
this driver it we can't really work with less than 4 ranges and don't
have memory for more than 4 bus handles for the ranges in the softc.
- Remove sc_range and sc_nrange from softc; for the bridges supported
by this driver we no longer need to know the ranges besides the bus
handles obtained from them once this driver is attached. That way we
also can free the memory allocated for sc_range during attach again.
- Remove sc_dvmabase from the softc and pass it to psycho_iommu_init()
via an additional argument as we no longer need to know the DVMA base
in this driver once the IOMMU is initialized.
- Remove sc_dmatag from the softc, there isn't much sense in keeping
the nexus dma tag around locally.
PR: 88279 [1]
Info from: OpenSolaris [1]
Tested by: kensmith [1]
MFC after: 1 month
|
|
|
|
|
|
|
|
|
|
| |
Simplify the shell scripting a bit, and remove a useless grep | sed
The problem was pointed out by the PR, and I used part of the solution
suggested there, but the semantics changed again for 9.2.x -> 9.3.x.
PR: conf/74228
Submitted by: Jeremy Chadwick <freebsd@jdc.parodius.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
between this driver and other Host-PCI bridge drivers based on this one:
- Make the code fit into 80 columns.
- Make the code adhere style(9) (don't use function calls in initializers,
use uintXX_t instead of u_intXX_t, add missing prototypes, ...).
- Remove unused and superfluous struct declaration, softc member, casts,
includes, etc.
- Use FBSDID.
- Sprinkle const.
- Try to make comments and messages consistent in style throughout the
driver.
- Use convenience macros for the number of interrupts and ranges of the
bridge.
- Use __func__ instead of hardcoded function names in panic strings and
error messages. Some of the hardcoded function names actually were
outdated through moving code around. [1]
- Rename softc members related to the PCI side of the bridge to sc_pci_*
in order to make it clear which side of the bridge they refer to (so
stuff like sc_bushandle vs. sc_bh is less confusing while reading the
code).
PR: 76052 [1]
|
| |
|
|
|
|
|
| |
Noticed by: pjd
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
| |
- Use _prestart rc.d method to automatically kldload ng_btsocket(4) if needed;
- Rename "sdpd_user" to "sdpd_username" and "sdpd_group" to "sdpd_groupname"
to avoid collision with "magic" variables;
Inspired by: yar
MFC after: 3 days
|
|
|
|
|
|
| |
on it.
- Sync with sys/conf/files* and build pcf_isa.c only on i386 for now.
- Try to adhere to style.Makefile(5) (sorting, whitespace).
|
|
|
|
|
|
| |
additionally on ebus(4) as the 'SUNW,envctrl' devices (as well as
'SUNW,envctrltwo' and 'SUNW,rasctrl', which we might want to also
support in envctrl.c in the future) are only found on EBus.
|
|
|
|
|
|
|
|
|
| |
on powerpc (more or less...). That way people updating from FreeBSD 5 to
FreeBSD 6 and beyond on sparc64 will get an error from config(8) rather
than a mysterious compile error when they have a stale 'device zs' in
their kernel config file.
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ofw_bus_gen_get_*() for providing the ofw_bus KOBJ interface in order
to reduce code duplication.
- While here sync the various sparc64 bus drivers a bit (handle failure
to attach a child gracefully instead of panicing, move the printing
of child resources common to bus_print_child() and bus_probe_nomatch()
implementations of a bus into a <bus>_print_res() function, ...) and
fix some minor bugs and nits (plug memory leaks present when attaching
a bus or child device fails, remove unused struct members, ...).
Additional testing by: kris (central(4) and fhc(4))
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a newly introduced struct ofw_bus_devinfo which can hold the OFW info
of a device recallable via the ofw_bus KOBJ interface. Introduce a set
of functions ofw_bus_gen_get_*() which use ofw_bus_default_get_devinfo()
to provide generic subroutines for implementing the rest of the ofw_bus
KOBJ interface in a bus driver.
This is inspired by bus_get_resource_list() and bus_generic_rl_*_resource()
and allows to reduce code duplication in bus drivers as they only have
to provide an ofw_bus_default_get_devinfo() implementation in order to
provide the ofw_bus KOBJ interface via ofw_bus_gen_get_*().
- While here add a comment to ofw_bus_if.m describing the intention of
the ofw_bus KOBJ interface.
Reviewed by: marcel
|
| |
|
|
|
|
|
|
| |
since re_rxeof() drops the lock for some time.
Reported & tested by: XueFeng Deng <dsnofe yahoo.com.cn>
|
|
|
|
|
|
| |
by a user. Instead, add individual checks as dependencies to
the main "installcheck" target. Make sure that installkernel
etc. depend on it (including the UID/GID checks).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If the complete reply on the TRANS2_FIND_FIRST2 request fits exactly
into one responce packet, then next call to TRANS2_FIND_NEXT2 will return
zero entries and server will close current transaction. To avoid
subsequent errors we should not perform FIND_CLOSE2 request.
PR: kern/78953
Submitted by: Jim Carroll
|
|
|
|
|
|
|
| |
as cmbat.
Reviewed by: njl
MFC after: 3 days
|