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
pushout was called with NULL argument. This has the semantic of using a
working directory of "/", even though already read plist entries are
relative to prefix. The calls to chown and chgrp therefore end up with
the wrong arguments for the current directory. To compensate for this,
don't pushout the first time. As plists are not supposed to have
multiple @cwd entries anymore, this could most likely be simplified, but
that is outside the scope of this commit.
Reviewed by agc@
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.
advantages of our ksh (emacs line editing). There were objections against
using ksh, because our (pd)ksh is not the real ksh. See also the
discussion on tech-userlevel.
Motivation for changing the default from csh is better interactive
usability and desire to use a standard shell, which is already used for
all the system shell scripts.
Approved by core.
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.
