Also, add ioctls SIOCGIFADDRPREF/SIOCSIFADDRPREF to get/set preference
numbers for addresses. Make ifconfig(8) set/display preference
numbers.
To activate source-address selection policies in your kernel, add
'options IPSELSRC' to your kernel configuration.
Miscellaneous changes in support of source-address selection:
1 Factor out some common code, producing rt_replace_ifa().
2 Abbreviate a for-loop with TAILQ_FOREACH().
3 Add the predicates on IPv4 addresses IN_LINKLOCAL() and
IN_PRIVATE(), that are true for link-local unicast
(169.254/16) and RFC1918 private addresses, respectively.
Add the predicate IN_ANY_LOCAL() that is true for link-local
unicast and multicast.
4 Add IPv4-specific interface attach/detach routines,
in_domifattach and in_domifdetach, which build #ifdef
IPSELSRC.
See in_getifa(9) for a more thorough description of source-address
selection policy.
To avoid code duplication, move strsep.c to the kernel/userland
common files.
Soon I will commit source-address selection (options IPSELSRC).
It will use strsep(3).
I'm not sure what it exactly means, but at least, the packet in question
is reloaded in ex_txstat() and should not handle the Dn Complete event
at the moment --- it should be served on later interrupt.
- Reload packet on collision, too.
more flexible
- account a number of free txq and use it to see if packets are queued or sent
- assume free TX descriptors are not owned by the chip in re_start() and
panic if there is any inconsistency on them #ifdef DIAGNOSTIC case.
- replace a magic number (reserved TX descs?) with macro
event should be raised every 10ms if we're runnable. Unfortunately,
there seems to be an intermittent bug in the hypervisor such that,
for about 1<<32 ns (~4.3s) after it manifests, every running domain
continues to run but not get its timer events and new timestamps (nor
is it preempted in favor of other domains on that CPU). This can cause
strange behavior from our timekeeping; for example, hardclock() is never
called during this interval.
So here's a workaround: if timestamp is allegedly up to date but is more
than 40ms old (this is semi-arbitrary), the domain sets its timer to a
time in the past, which causes it to become immediately pending, and also
results in the publication of a new timestamp.
I'm leaving those platforms with few users and those whose machines are
not very powerful untouched per uwe@'s suggestion. The port masters or
the real users of those ports are better suited to make the decision of
enabling it.
(I did this because the system could panic otherwise. But this seemed to
be a side-effect of another mistake that was present in the code before it
was commited. So effectively this simplification should have happened
before.)
- check status bits at once (I'm not sure how gcc optimized them though)
- no need to check (ifp->if_flags & IFF_UP) twice
(re_init() must be called at splnet() anyway)
- call re_start() only if the interrupt is actually handled here
- call re_start() directly rather than via (*ifp->if_start)()
if not, fallback to VOP_READ and VOP_WRITE. This makes vnd work with files
on, e.g. tmpfs and smbfs; all file systems should behave as before.
OK'ed by silence in tech-kern@.
- split mkclock attachment from sparc64/clock.c into dev/mkclock.c
(now clock.s only contains clock interrupt and timecounter stuff)
- rename match/attach functions of rtc at ebus to match the device name
- update some comments around clock devices in GENERIC
No objection on port-sparc64 for a month.
- Remove useless (thanks to COMPAT_XX behaviour) #ifdefs in
syscalls.master
- Make netbsd32_compat_43.c compiled per COMPAT_LINUX32 because the latter
needs stuff from it.
Fixes Perry's PR#34951.
"The Certance CP3100 product family provides high-end disk-to-disk-to-tape
(D2D2T) functionality for small-to-medium businesses."
To software, the unit is very similar to the IQ80321 and IQ31244 eval
boards from Intel. As such, we share almost all of their code.
Onboard hardware:
- IOP321 XScale CPU. Core clock is 600MHz.
- 256MB SDRAM (not sure if that's true for all)
- Four-port Intel i31244 SATA controller. One port is connected to the
internal disk. The remaining three are available on the back-panel.
- Dual GigE ports on the back panel, using an Intel i82546EB controller.
- Two Symbios Logic 53c1010 SCSI controllers, one in host mode the other
in target mode. Both SCSI busses are available on the back panel.
Note that NetBSD does not support SCSI target mode.
- 8MB of NOR Flash, containing a fairly vanilla Redboot together with
a minimal compressed Linux image.
- Some front-panel LEDS (not supported).
- Serial console.
Contributed by Wasabi Systems, Inc.
devices hooked up to the HPI pin.
HPIs cannot be masked at the interrupt controller; they can only be masked
by disabling IRQs in the XScale core. To deal with this, we tweak the
interrupt frame so that IRQs are disabled when the interrupt dispatcher
returns due to a masked HPI interrupt. IRQs will be re-enabled by a
subsequent splx(9).
Fortunately the only instance where HPI is used is for the console UART
on a couple of boards, so this hack does not adversely affect performance.
Contributed by Wasabi Systems.
implies that _UC_CPU must be set in the context passed. Check for this
and return EINVAL if not; this gives a cheap test for corrupted
ucontexts eg on a signal handler stack which would go unnoticed otherwise.
-Don't ckeck for NULL ucontext pointers explicitely. This is an error,
except in the swapcontext() case where it can be easily caught in
userland.
mmap and therefore execution of binaries starting to work, some
speed improvements with large file I/O also. caching semantics
and error case handling most likely need revisiting.
required to initialize ksyms_hdr. Otherwise LKMs do not work when using
ksyms_init_explicit instead of ksyms_init, as is the case of booting an
i386 kernel using Multiboot.
predictable. This solves a problem that may appear when serving a tmpfs
over NFS: if the server reboots, newly allocated files should have
different file handles; otherwise the remote clients could access files
they were not supposed to touch.
not persistent across reboots but neither are those of MFS, which we are
trying to replace. We should probably warn the user somehow, but not
prevent him doing this if he really wants to.
While here add a "reply" to the code-style change item.
binaries which cast the returned values to 64-bits and fail due to sign
expansion. More details are provided in the big comment in tmpfs.h that
describes how the new tmpfs_dircookie works.
This is a rather ugly hack that shall be fixed with a cleaner solution,
but this resolves the problem in an effective way.
Fixes kern PR/32034.
from RTK_ or rtk_ to RE_ or re_ for maintainability of these sources.
Eventually we should split these files (and struct rtk_softc) into
three elements, rtk(4) specific one, re(4) specific one, and a common
(register definitions, eeprom and multicast functions etc) part.
While here, add a couple of comments around weird definitions.
like Tx underrun.
This should improve performance on such errors.
Handle fifo threshold properly --- actually it did not handled at all.
Note that the Tx Complete interrupts occur only on errors, and ex_txstat()
is not good place to increment sc->tx_succ_ok. Increase the sc->tx_succ_ok
count from 100 to 256, since the ex(4) does busmastering and underruns
should rarely happen in normal operations.
Possibly improve some situation for the hang-on-heavy-load problems,
such as kern/11450 and kern/27096.
it could be lost if bus_dmamap_load_mbuf(9) returns EFBIG.
(though I've never seen the "too mamy segments" message
which indicates the packet has more than 32 fragments)
committed in rev 1.22), save it before calling m_defrag().
I haven't confirmed whether the m_pkthdr.csum_flags is preserved during
m_defrag(), but the previous way sometimes makes vge(4) chip mad...
Perform hardware diagnostic only on the original RTL8169,
which was the only device that really needed it.
(i.e. a possible hardware bug when the NIC was put on a 64bit PCI slot)
Tested with on-board 8139C+ by Brian A. Seklecki.
Note this change might also fix PR kern/34952
(because re_diag() is no longer called on 8169S/8110S),
but I'm not sure if the re(4) chip was properly initialized in such case.
- move some driver specific definitions from rtl81x9reg.h to rtl81x9var.h
- move several macro where related structures are declared
- remove unused macro
- fix some comments
- unwrap some lines
from FreeBSD's if_vr.c rev 1.52:
- check more error status in TX descriptor and restart TX module
appropriately in vr_txeof()
- check more error interrupt status in vr_intr()
I can't confirm whether these changes actually fix TX stalls because
I can't reproduce the problem I had about seven years ago (I guess
it might be caused by excessive collisions on a dumb hub), but at least
they don't seem to have bad side effects on normal operations on my macppc.
those not tied up in active mbufs, rather than half of the total number.
(Or, to more literally translate the C, when there are at least as
many buffers waiting to be reused as outstanding rx requests.)
This prevents us from dropping off the network for a while when more
than 128 of the 256 buffers are in use by mbufs, which might not be
freed for an arbitrarily long time; the remaining buffers would stack up
on the free list but not be reclaimed until enough mbufs were eventually
freed, leaving the interface unable to receive packets until then.
Checking all zsc units in zshard() is efficient only on ports
which share one interrupt among all zsc units, like sparc or sun3.
On such ports, zshard() is established as a handler only once.
XXX1: more other MD zs drivers should be fixed similarly.
XXX2: zsc on macppc has independent interrupts for channel A and B,
but MI z8530sc can't handle such configuration.
reference to the parent directory's vnode instead of its smbnode to
avoid a use-after-free bug causing a panic when a smbfs mount is
forcefully unmounted.
Keep trying to flush the vnode list for the mount while some are still
busy and we are making progress towards making them not busy. This
stops attempts to unmount idle smbfs mounts failing with EBUSY.
The easiest way to reproduce the above problem, from what I have seen is:
1) Assume /s is a smbfs mount point.
2) mount /s
3) stat /s/foo/1
4) umount /s
Returns error because the file system is busy.
5) Shutdown the machine: panic in smbfs_reclaim because vrele
accesses already-released memory.
The commit log in FreeBSD's if_vr.c rev 1.43 says
"This is really only for the VT6102, but it doesn't hurt the older chips,"
but at least it hurts my VT86C100A (which returns a product ID of VT3043)
on macppc and causes kernel MCHK trap while the same board on i386
and VT6102 on macppc have no problem with it.
array's contents and returning all the requested pages. Otherwise there
are problems (accessing invalid memory) when the a_m vector is passed
uninitialized as the NFS server code does. Fixes PR kern/34959.
Note that this is not a "real" fix. While this makes tmpfs's getpages
operation consistent with the behavior of other file systems, it does
not resolve the different semantics between uvn_get and uao_get as
described in PR kern/32166. I'm adding a comment in the code mentioning
exactly this so that it can be reviewed when this last problem is
addressed.
