shared signal handling when there is shared signal handling being
used.
This removes the main objection to making the shared signal handling
a standard ability in rfork() and friends and 'unconditionalising'
this code. (i.e. the allocation of an extra 328 bytes per process).
Signal handling information remains in the U area until such a time as
it's reference count would be incremented to > 1. At that point a new
struct is malloc'd and maintained in KVM so that it can be shared between
the processes (threads) using it.
A function to check the reference count and move the struct back to the U
area when it drops back to 1 is also supplied. Signal information is
therefore now swapable for all processes that are not sharing that
information with other processes. THis should addres the concerns raised
by Garrett and others.
Submitted by: "Richard Seaman, Jr." <dick@tar.com>
to release the probe ccb before taking down the periph.
Also, don't do cdscheduling if you're not going to
attach the device after all.
Reviewed by: ken@freebsd.org
from sc, vt and sio drivers. Use instead a linker_set to collect them.
Staticize ??cngetc(), ??cnputc(), etc functions in sc and vt drivers.
We must still have siocngetc() and siocnputc() as globals because they
are directly referred to by i386-gdbstub.c :-(
Oked by: bde
already loaded and interpreted userconfig_script. Otherwise, when using
such kernel system would always block waiting for user input in UserConfig,
while the intention was to avoid this by having userconfig_script.
Reviewed by: msmith
that they might be about to blow their feet off if they have not been
reading their mail. I don't know if or how well this will work, but it's
worth a try.
It keeps returning queue full until we have reduced the number of tagged
openings to the minimum.
So, put in a quirk entry with the same work-around. This quirk entry is
only for the 9G Atlas III, once someone comes up with inquiry information
for the 18G version of that drive, we can quirk it as well.
Submitted by: "Johan Granlund" <johan@granlund.nu>
downward growing stacks more general.
Add (but don't activate) code to use the new stack facility
when running threads, (specifically the linux threads support).
This allows people to use both linux compiled linuxthreads, and also the
native FreeBSD linux-threads port.
The code is conditional on VM_STACK. Not using this will
produce the old heavily tested system.
Submitted by: Richard Seaman <dick@tar.com>
MNT_WAIT when we mean boolean `true' or check for that value not being
passed. There was no problem in practice because MNT_WAIT had the
magic value of 1.
and mx_setcfg() so that we can read the internal MII registers on the
MX98713 chip correctly. With these changes, media autoselection now
works correctly on the original 98713. All Macronix chips should now
be properly supported (unless there's a surprise waiting in the 98725).
Thanks to Ulf Zimmermann for providing a 98713 board.
list of devices which has been changed in UserConfig, without resorting
to reading /dev/kmem.
The data returned consist of series of struct isa_device and
char dev_name[8].
Ok'd by: jkh
the quirk that disables tagged queueing for those drives.
Also, silence a warning by disabling xpt_for_all_targets() and
xpt_for_all_periphs(). These two functions are not currently used, but
they should not be removed. They're part of a set of functions that
provide a way to execute a function for every {bus,target,device,periph} in
the system.
If anyone needs to use either function in the future, they can be
un-#ifdefed.
is enough to satisfy things like StarOffice. This is a hack, but doing
it properly would be a LOT of work, and would require extensive grovelling
around in the user address space to find the argv[].
Obtained from: Mostly from Andrzej Bialecki <abial@nask.pl>.
isolated to revision 33 PNIC chips is also present in revision 32 chips.
Cards with rev. 32 chips include the LinkSys LNE100TX and the Matrox
FastNIC 10/100. This accounts for all the cards that I have to test
with.
(I was never able to personally trip the bug on this chip rev, but today
one of the guys in the lab did it with the software they're working on
for their cellular IP project, which uses BPF and promiscuous mode
extensively.)
This commit enables the promiscuous mode software workaround code for
both revison 32 and revision 33 chips. It's possible all of the PNIC
chips suffer from this bug, but these are the only two revs where I
know for a fact it exists.
CAPACITY fail for a non-removable media device. There's a race
condition where the device entry is removed and then
xpt_release_ccb is called which attempts to give back the ccb
to a device that's now gone. In this bandaid release the ccb
early and then remember to not call xpt_release_ccb later.
- Special registers of IO-DATA device's RSA series are defined in
ic/rsa.h (new file).
Pointed out by: Bruce Evans <bde@zeta.org.au>
Submitted by: Takahashi Yoshihiro <nyan@wyvern.cc.kogakuin.ac.jp>
Noticed by: Carl Mascott <cmascott@world.std.com>
Don't write access time of a file more than once per day. (Its precision is
1 day anyway). Don't try to write access and creation time in nonwin95 case.
Suggested by: bde (long time ago).
used in device attach routines. At least for attaches at boot time,
actually waiting, or actually failing for malloc(..., M_NOWAIT), are
almost equally unlikely and harmless, but using M_WAITOK interferes
with automatic detection of bogus M_WAITOK's.
deltas, but it is possible since I had a few merge conflicts over the last
few days while this has been sitting ready to go.
(Part 1 was committed to the config files, but cvs aborted grrr..)
Approved by: core
I/O requests must be marked P_SYSTEM because if it isn't and the system
decides to swap it or (god forbid) kill it, the system stands a good
chance of locking up.
chip revisions. (A buggy taiwanese chip? I'm just shocked; shocked I tell
you.) So far I have only observed the anomalous behavior on board with
PCI revision 33 chips. At the moment, this seems to include only the
Netgear FA310-TX rev D1 boards with chips labeled NGMC169B. (Possibly this
means it's an 82c169B part from Lite-On.)
The bug only manifests itself in promiscuous mode, and usually only at
10Mbps half-duplex. (I have not observed the problem in full-duplex mode,
and I don't think it ever happens at 100Mbps.) The bug appears to be in
the receiver DMA engine. Normally, the chip is programmed with a linked
list of receiver descriptors, each with a receive buffer capable of holding
a complete full-sized ethernet frame. During periods of heavy traffic
(i.e. ping -c 100 -f 8100 <otherhost>), the receiver will sometimes appear
to upload its entire FIFO memory contents instead of just uploading the
desired received frame. The uploaded data will span several receive
buffers, in spite of the fact that the chip has been told to only use
one descriptor per frame, and appears to consist of previously transmitted
frames with the correct received frame appended to the end.
Unfortunately, there is no way to determine exactly how much data is
uploaded when this happens; the chip doesn't tell you anything except the
size of the desired received frame, and the amount of bogus data varies.
Sometimes, the desired frame is also split across multiple buffers.
The workaround is ugly and nasty. The driver assembles all of the data
from the bogus frames into a single buffer. The receive buffers are always
zeroed out, and we program the chip to always include the receive CRC
at the end of each frame. We therefore know that we can start from the
end of the buffer and scan back until we encounter a non-zero data byte,
and say conclusively that this is the end of the desired frame. We can
then subtract the frame length from this address to determine the real
start of the frame, and copy it into an mbuf and pass it on.
This is kludgy and time consuming, but it's better than dropping frames.
It's not too bad since the problem only happens at 10Mbps.
The workaround is only enabled for chips with PCI revision == 33. The
LinkSys LNE100TX and Matrox FastNIC 10/100 cards use a revision 32 chip
and work fine in promiscuous mode. Netgear support has confirmed that
they "have some previous knowledge of problems in promiscuous mode" but
didn't have a workaround. The people at Lite-On who would be able to
suggest a possible fix are on vacation. So, I decided to implement a
workaround of my own until I hear from them. I suppose this problem made
it through Netgear's QA department since Windows doesn't normally use
promiscuous mode, and if Windows doesn't need the feature than it can't
possibly be important, right? Grrr.
key? ( -- flag) \ check to see if there's a key to be read from input
ms ( u -- ) \ wait that many milliseconds
seconds ( -- u ) \ get number of seconds from midnight.
'words' now outputs the list page by page - this probably should go
through libstand's pager, but will have to wait for closer integration of
built-ins with Forth...
Submitted partially by: W Gerald Hicks <wghicks@bellsouth.net>
this has a problem with capture but i am not sure if it is related
to the mixer or what else.
But in the meantime, this is ok to listen to mpegs.
I also have a much simpler version of the driver in the works which
reuses a lot more of the existing "pcm" routines. Next year...
