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.
