comes in for it, the file is really gone, so return ESTALE.
The problem arises when the last reference to an FFS file is
released because soft-updates may delay the actual freeing of the
inode for some time. Since there are no filesystem links or open
file descriptors referencing the inode, from the point of view of
the system, the file is inaccessible. However, if the filesystem
is NFS exported, then the remote client can still access the inode
via ufs_fhtovp() until the inode really goes away. To prevent this
anomoly, it is necessary to begin returning ESTALE at the same time
that the file ceases to be accessible to the local filesystem.
Obtained from: Ian Dowse <iedowse@maths.tcd.ie>
If for some reason DEVFS is undesired, the "NODEVFS" option is
needed now.
Pending any significant issues, DEVFS will be made mandatory in
-current on july 1st so that we can start reaping the full
benefits of having it.
pcb for fork(). It was possible for the state to be saved twice when an
interrupt handler saved it concurrently. This corrupted (reset) the state
because fnsave has the (in)convenient side effect of doing an implicit
fninit. Mundane null pointer bugs were not possible, because we save to
an "arbitrary" process's pcb and not to the "right" place (npxproc).
Push the parent's %gs to the pcb for fork(). Changes to %gs before
fork() were not preserved in the child unless an accidental context
switch did the pushing. Updated the list of pcb contents which is
supposed to inhibit bugs like this. pcb_dr*, pcb_gs and pcb_ext were
missing. Copying is correct for pcb_dr*, and pcb_ext is already
handled specially (although XXX'ly).
Reducing the savectx() call to an npxsave() call in rev.1.80 was a
mistake. The above bugs are duplicated in many places, including in
savectx() itself.
The arbitraryness of the parent process pointer for the fork()
subroutines, the pcb pointer for savectx(), and the save87 pointer
for npxsave(), is illusory. These functions don't work "right" unless
the pointers are precisely curproc, curpcb, and the address of npxproc's
save87 area, respectively, although the special context in which they
are called allows savectx(&dumppcb) to sort of work and npxsave(&dummy)
to work. cpu_fork() just doesn't work unless the parent process
pointer is curproc, or the caller has pushed %gs to the pcb, or %gs
happens to already be in the pcb.
when PC98 is defined. This is in perparation for a mecia driver
separate from pcic, assuming that all goes well with that effort.
MECIA_SUPPORT won't be removed until after that support is working.
of the pcic class of devices. Go ahead and move it to the "usual"
place. I say "usual" in quotes since it isn't exactly right (not in
dev/blah), but it is closer than before.
softc.
o Store pointers to softc in dev_t in si_drv1.
o Change 'kludge version' to 'classic version' since things are getting less
kludgy.
o Minor code shuffling so that we probe and attach the pccard slots.
o Minor style(9) changes.
follow Linux' convention and use %gs. This adds back the setting of
%fs to a sane value in sendsig(). The value of %gs remains preserved
to whatever it was in user context.
handler in Linux emulation. According to bde, this is what Linux
does.
Recent versions of linuxthreads use %gs for thread-specific data,
while FreeBSD uses %fs (mostly because WINE uses %gs).
Tested by: drew
KASSERT when vp->v_usecount is zero or negative. In this case, the
"v*: negative ref cnt" panic that follows is much more appropriate.
Reviewed by: mckusick
fail due to witness exhausting its internal resources and shutting down.
Reported by: Szilveszter Adam <sziszi@petra.hos.u-szeged.hu>
Tested by: David Wolfskill <david@catwhisker.org>
much more often that expected and negatively impact performance when
running at 100mbps. I need to figure out if there's a better way to
handle this, but for now this shouldn't hurt anything.
and DP83821 gigabit ethernet MAC chips and the NatSemi DP83861 10/100/1000
copper PHY. There are a whole bunch of very low cost cards available with
this chipset selling for $150USD or less. This includes the SMC9462TX,
D-Link DGE-500T, Asante GigaNIX 1000TA and 1000TPC, and a couple cards
from Addtron.
This chip supports TCP/IP checksum offload, VLAN tagging/insertion.
2048-bit multicast filter, jumbograms and has 8K TX and 32K RX FIFOs.
I have not done serious performance testing with this driver. I know
it works, and I want it under CVS control so I can keep tabs on it.
Note that there's no serious mutex stuff in here yet either: I need
to talk more with jhb to figure out the right way to do this. That
said, I don't think there will be any problems.
This driver should also work on the alpha. It's not turned on in
GENERIC.
a LinkSys card here in the office where reading the station address
fails the first time, but works find afterwards. Without this, the
probe fails. I don't think this will negatively impact any existing
cards, but I want to confirm this before MFC'ing.
safe from preemption and concurrent access to the LDT.
- Move the prototype for i386_extend_pcb() to <machine/pcb_ext.h>.
Reviewed by: silence on -hackers
we need to delete the info from the list as well as zero out the res
pointer we saved in the code.
Also made a few style(9) changes while I was at it. Don't use if
(ptr) or if (!ptr), but compare against NULL. Compare against NULL
rather than 0. Don't have useless blocks.
There are likely other problems as well, but at least the wi based
wireless card with memory listed in its cis doesn't panic the system
when the card is inserted.
use TAILQ macros. The sk_attach_xmac() routine calls sk_init_xmac()
before doing the transceiver probe, but *before* ether_ifattach()
is called. This causes sk_init_xmac() to call sk_setmulti(), which
tries to do a TAILQ_FOREACH(), which it can't do because ether_ifattach()
hasn't done a TAILQ_INIT() yet. This causes a NULL pointer dereference
and panic in sk_setmulti() at driver load/initialization time.
Fixed by calling ether_ifattach() before the MII probe.
The code in RELENG_4 still uses the old way of enumerating the
multicast list and doesn't have this problem. Yet.
