- this causes POSIX locking to use the thread group leader
(p->p_leader) as the locking thread for all advisory locks.
In non-kernel-threaded code p->p_leader == p, so this will have
no effect.
This results in (more) correct POSIX threaded flock-ing semantics.
It also prevents the leader from exiting before any of the children.
(so that p->p_leader will never be stale) in exit1().
We have been running this patch for over a month now in our lab
under load and at customer sites.
Submitted by: John Plevyak <jplevyak@inktomi.com>
This means that the driver will add/delete routes when it knows it is
up/down, rather than have the generic code belive it is up if configured.
This is probably most useful for serial lines, although many PHY chips
could probably tell us if we're connected to the cable/hub as well.
Insure that device mappings get MAP_PREFAULT(_PARTIAL) set,
so that 4M page mappings are used when possible.
Reviewed by: Luoqi Chen <luoqi@watermarkgroup.com>
txdr_hyper and fxdr_hyper tweaks to avoid excessive CPU order knowledge.
nfs_serv.c: don't call nfsm_adj() with negative values, windows clients
could crash servers when doing a readdir of a large directory.
nfs_socket.c: Use IP_PORTRANGE to get a priviliged port without a spin
loop trying to bind(). Don't clobber a mbuf pointer or we get panics
on a NFS3ERR_JUKEBOX error from a server when reusing a freed mbuf.
nfs_subs.c: Don't loose st_blocks on NFSv2 mounts when > 2GB.
Obtained from: OpenBSD
corresponding variable `rc_wakeup_started' in rev.1.36 but broken
again in rev.1.37. This bug only caused excessive polling (it gave
NRC activations for each of the SWI handler and the timeout handler
instead of 1 of each).
Moved cdevsw attachment from the driver probe routine to the driver
attach routine.
flag to the kernel to mount a CDROM as the root filesystem. Alternatively,
the boot_cdrom env var can be set.
As Mike Smith noted, "-C is the "wrong" way to do this", but this is
an acceptable stopgap in lieu of a better way.
PR: bin/11884
Reviewed by: msmith@freebsd.org
to either enqueue or free their mbuf chains, but tcp_usr_send() was
dropping them on the floor if the tcpcb/inpcb has been torn down in the
middle of a send/write attempt. This has been responsible for a wide
variety of mbuf leak patterns, ranging from slow gradual leakage to rather
rapid exhaustion. This has been a problem since before 2.2 was branched
and appears to have been fixed in rev 1.16 and lost in 1.23/1.28.
Thanks to Jayanth Vijayaraghavan <jayanth@yahoo-inc.com> for checking
(extensively) into this on a live production 2.2.x system and that it
was the actual cause of the leak and looks like it fixes it. The machine
in question was loosing (from memory) about 150 mbufs per hour under
load and a change similar to this stopped it. (Don't blame Jayanth
for this patch though)
An alternative approach to this would be to recheck SS_CANTSENDMORE etc
inside the splnet() right before calling pru_send() after all the potential
sleeps, interrupts and delays have happened. However, this would mean
exposing knowledge of the tcp stack's reset handling and removal of the
pcb to the generic code. There are other things that call pru_send()
directly though.
Problem originally noted by: John Plevyak <jplevyak@inktomi.com>
New function getmemsize_pc98 is added in this commit, since PC98 is
quite different in obtaining memory size from IBM-PC. Many lines of
this function is shareable with IBM-PC's getmemsize function, but
sharing needs many #ifdef PC98 statements. Therefore, I gave up
sharing code with IBM-PC's and just added new function.
happens if you have a BIOS with a 'Plug & Play OS' setting and you leave
it set to 'Yes.' This is wrong for FreeBSD (and LoseNT): it should be set
to 'No.' Apparently it's still possible to map the iobase of the NIC and
have the card work by reading the config space manually (which is what
the driver does if pci_map_port() fails) but we need to warn the user to
do fix their machine anyway. Anyway, warn the user to check the 'Plug &
Play OS' setting in their BIOS if mapping the io space fails.
The driver now identifies the IBM PCI-PCI Bridge fitted to newer
Matrox cards and initialises it.
Sumitted by: Anton Berezin <tobez@plab.ku.dk>
The Protein Laboratory, University of Copenhagen
via an IBM PCI-PCI bridge (82351 or 82352 or 82353)
The driver must identify if it is on a secondary PCI bus, which is
created via the IBM PCI-PCI bridge. If it is, then it must initialise
the IBM PCI-PCI bridge correctly.
To do this, the following new functions are added.
Because they use the pcici_t tag, they are considered 2.2 compatibility APIs
pcici_t * pci_get_parent_from_tag(pcici_t tag);
int pci_get_bus_from_tag(pcici_t tag);
(The _from_tag suffix is used to prevent clashes with similarly named
newbus PCI API functions)
Submitted by: Anton Berezin <tobez@plab.ku.dk>
Reviewed by: Doug Rabson <dfr@nlsystems.com>
Reworked by: Me (roger)
The cdevsw_add() function now finds the major number(s) in the
struct cdevsw passed to it. cdevsw_add_generic() is no longer
needed, cdevsw_add() does the same thing.
cdevsw_add() will print an message if the d_maj field looks bogus.
Remove nblkdev and nchrdev variables. Most places they were used
bogusly. Instead check a dev_t for validity by seeing if devsw()
or bdevsw() returns NULL.
Move bdevsw() and devsw() functions to kern/kern_conf.c
Bump __FreeBSD_version to 400006
This commit removes:
72 bogus makedev() calls
26 bogus SYSINIT functions
if_xe.c bogusly accessed cdevsw[], author/maintainer please fix.
I4b and vinum not changed. Patches emailed to authors. LINT
probably broken until they catch up.
chipset. First you thrilled to the 3c905, then you trembled at the
3c905B, now gaze in wonder at: the 3c905C! This appears to be another
3c90X series chip called the Tornado (PCI ID 0x10B7/0x9200) and should
be equivalent (from the driver API perspective) to the 3c905B, so all
we have to do is add the PCI ID to the list.
Reformat and initialize correctly all "struct cdevsw".
Initialize the d_maj and d_bmaj fields.
The d_reset field was not removed, although it is never used.
I used a program to do most of this, so all the files now use the
same consistent format. Please keep it that way.
Vinum and i4b not modified, patches emailed to respective authors.
of the current interrupt trasaction.
- Do not schedule the next interrupt transaction if the pipe is being
aborted or the last round of the interrupt transaction ended with error.
Submitted by: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
- Call ums_disable() to abort the pipe.
- Do not wake up processes which has been waiting or polling for mouse
data. It won't be available anymore.
Submitted by: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
use ALPHA_PHYS_TO_K0SEG(offset) rather than just plain offet. I've verified
that this does not break other platforms (I've tested an AlphaStation 200
and a Personal Workstation 500au with this patch).
As to why this works, well.. Its black magic as far as I know. I obtained
this hack from Myricom, who in turn, obtained it from Compaq engineers.
Without this hack, XFree86 cannot talk to a PCI graphics card.
Reviewed by: Doug Rabson <dfr@nlsystems.com>
Obtained from: feldy@myri.com (Bob Felderman)
similar to the PNIC I (supported by the pn driver). In fact, it's really
a Macronix 98715A with wake on LAN support added. According to LinkSys,
the PNIC II was jointly developed by Lite-On and Macronis. I get the
feeling Macronix did most of the work. (The datasheet has the Macronix
logo on it, and is in fact nearly identical to the 98715 datasheet, except
for the extra wake on LAN registers.) In any case, the PNIC II works just
fine with the Macronix driver.
The changes are:
- Move PCI ID for the PNIC II from the pn driver to the mx driver.
- Mention PNIC II support in mx.4.
- Mention PNIC II support in RELNOTES.TXT and HARDWARE.TXT.
