| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
turn it back on. Specifically, the actual changes are now less intrusive
in that the _get_spin_lock() and _rel_spin_lock() macros now have their
contents changed for UP vs SMP kernels which centralizes the changes.
Also, UP kernels do not use _mtx_lock_spin() and no longer include it. The
UP versions of the spin lock functions do not use any atomic operations,
but simple compares and stores which allow mtx_owned() to still work for
spin locks while removing the overhead of atomic operations.
Tested on: i386, alpha
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
panic curlen != 0, which is perfectly normal.
Approved by: mux
|
|
|
|
|
|
|
|
|
| |
to be the same as Boca Research Turbo Serial 654 (4 serial port).
While add the 8 port variants as well.
Submitted by: sten@blinkenlights.nl
PR: kern/75793
MFC after: 1 week
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main changes are:
1. Use of multiple bus dma tags.
2. Timing of CAM requests by the driver.
3, Firmware interface change relating to retrieving AEN's.
4. Removal of twa_intrhook.
5. Bundling of latest firmware with BBU capability.
Reviewed by:re
Approved by:re
|
|
|
|
|
| |
Expect caller to lock before calling sis_stop()
Various style stuff.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
in revision 1.141.
Lock assertion failures reported by: Kris Kennaway
|
|
|
|
| |
o Use capitalized "Ethernet" for consistency.
|
| |
|
|
|
|
|
|
|
| |
with some revisions of the chip (particularly when using multiple TX
descriptors).
MFC after: 1 week
|
|
|
|
| |
implemented "sis_nextdesc" pointer to keep a pointer instead.
|
|
|
|
|
|
|
| |
their fields directly in the softc structure.
This is a no-op which shortens most of the affected source lines
by N * 10 characters.
|
| |
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
| |
class is a reserved word in C++
Submitted by: Markus Brueffer < markus AT brueffer DOT de >
MFC after: 3 days
|
|
|
|
|
|
|
|
|
| |
interface as well. This is not an expected revision id per the
datasheet, but unfortunately there are such cards out there with
a 82557 chipset, and they want to use the 82503.
PR: kern/75739
Reported by: Andre Albsmeier <andre.albsmeier@siemens.com>
|
| |
|
|
|
|
|
|
|
|
| |
- Mark mount, unmount and nmount MPSAFE.
- Add a stub for _umtx_op().
- Mark open(), link(), unlink(), and freebsd32_sigaction() MPSAFE.
Pointy hats to: several
|
|
|
|
|
|
| |
the free'd element, and ultimate NULL deref of the failed allocation.
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
(we ignore it).
- Remove code used for handling spoil events, as spoiling is not possible
anymore, because we keep consumers open for writing all the time.
MFC after: 4 days
|
|
|
|
|
|
| |
all the time. Remove unused code then.
MFC after: 4 days
|
| |
|
| |
|
| |
|
|
|
|
| |
the partially implemented vnode-readoption code in vgonechrl().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After disscussing things I have decided to take the easy and
consistent 90% solution instead of aiming for the very involved 99%
solution.
If we allow forceful unmounts of DEVFS we need to decide how to handle
the devices which are in use through this filesystem at the time.
We cannot just readopt the open devices in the main /dev instance since
that would open us to security issues.
For the majority of the devices, this is relatively straightforward
as we can just pretend they got revoke(2)'ed.
Some devices get tricky: /dev/console and /dev/tty for instance
does a sort of recursive open of the real console device. Other devices
may be mmap'ed (kill the processes ?).
And then there are disk devices which are mounted.
The correct thing here would be to recursively unmount the filesystems
mounte from devices from our DEVFS instance (forcefully) and if
this succeeds, complete the forcefully unmount of DEVFS. But if
one of the forceful unmounts fail we cannot complete the forceful
unmount of DEVFS, but we are likely to already have severed a lot
of stuff in the process of trying.
Event attempting this would be a lot of code for a very far out
corner-case which most people would never see or get in touch with.
It's just not worth it.
|
| |
|
|
|
|
|
| |
there was no objection on the pc98 list when I asked if it could be
removed a while ago.
|
|
|
|
| |
style change: regularize tabbing
|
|
|
|
|
| |
o Move card from all architectures to just pc98. It is only needed there,
although real issues remain with NEWCARD's support of ISA devices.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
3C920B-EMB-WNM Integrated Fast Ethernet Controller
Submitter reports that the card appears to autonegotiate properly, and
operate well with high levels of NFS traffic.
PR: 75253
Submitted by: "Oleg V. Nauman" <oleg at reis dot zp dot ua>
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
| |
only one set is needed for either endianess. This also completes them for
big endian archs and fixes the compilation of libncp, netncp, etc. there.
Reviewed by: bp, rwatson
Compile tested on: i386, sparc64
MFC after: 1 week
|
|
|
|
| |
alternative is much worse.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
o Move the sysctls under debug.psm.* and hw.psm.* making them a bit
clearer and more consistent with other drivers.
o Remove the debug.psm_soft_timeout sysctl. It was introduced many
moons ago in r1.64 but never referenced anywhere.
o Introduce hw.psm.tap_threshold and hw.psm.tap_timeout to control
the behaviour of taps on touchpads. People might like to fiddle
with these if tapping seems to slow or too fast for them.
o Add debug.psm.loglevel as a tunable so that verbosity can be set
easily at boot-time (to watch probes and such) without having to
compile a kernel with options PSM_DEBUG=N.
|
|
|
|
|
|
| |
Spell NULL right in a KASSERT() panic message.
MFC after: 1 week
|
| |
|
|
|
|
|
|
| |
Submitted by: bkoenig at cs dot tu-berlin dot de
PR: 72238
MFC after: 2 weeks
|
|
|
|
|
|
| |
what is going on, to replace it. Slight formatting changes
Code here is alredy different to NetBSD.
MFC after: 1 week
|
|
|
|
|
|
| |
scatter gather segments.
MFC after: 1 week
|
| |
|
|
|
|
|
|
|
| |
that the RFC 793 specification for accepting RST packets should be
following. When followed, this makes one vulnerable to the attacks
described in "slipping in the window", but it may be necessary in
some odd circumstances.
|