| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
supports this.
|
| |
|
|
|
|
| |
PR: 125746
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- ad7418(4) uses an sx lock instead of a mtx since the iicbus(4) stuff it
calls can sleep (request_bus()). Also, I expanded the locking slightly
to serialize writes to data stored in the softc.
- Similarly, the icee(4) driver now uses an sx lock instead of a mutex.
I also removed the pointless OPENED flag and flags field from the softc.
- The locking for the ic(4) driver was a bit trickier:
- Add a mutex to the softc to protect softc data.
- The driver uses malloc'd buffers that are the size of the interface
MTU to send and receive packets. Previously, these were allocated
every time the interface was brought up and anytime the MTU was
changed, with various races that could result in memory leaks. I
changed this to be a bit simpler and more like other NIC drivers in
that we allocate buffers during attach for the default MTU size and
only reallocate them on MTU changes. The reallocation procedure
goes to some lengths with various flags to not replace either the
the receive or transmit buffers while the driver is busy receiving
or transmitting a packet.
- Store the device_t of the driver in the softc instead of detours into
new-bus using if_dunit from the ifnet and an even more bizarre detour
to get the softc instead of using if_softc.
- Drop the driver mutex when invoking netisr_dispatch() to pass the
packet up to IP.
- Use if_printf().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add an sx lock to the iic(4) driver to serialize open(), close(), read(),
and write and to protect sc_addr and sc_count in the softc.
- Use cdev->si_drv1 instead of using the minor number of the cdev to
lookup the softc via newbus in iic(4).
- Store the device_t in the softc to avoid a similar detour via minor
numbers in iic(4).
- Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4)
instance, and do it in the child driver.
- Add a mutex to the iicbus(4) softc to synchronize the request/release bus
stuff.
- Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own.
- Add a mutex to the iicsmb(4) softc to protect softc state updated in the
interrupt handler.
- Remove Giant from all the smbus methods in iicsmb(4) now that all the
iicbus(4) backend is locked.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Just grab Giant in the ixp425_iic(4) driver since this driver uses
a shared address/data register window pair to access the actual
I2C registers. None of the other ixp425 drivers lock access to these
shared address/data registers yet and that would need to be done before
this could use any meaningful locking.
- Add locking to the interrupt handler and 'iicbus_reset' methods of the
at91_twi(4) driver.
- Add locking to the pcf(4) driver. Other pcf(4) fixes include:
- Don't needlessly zero the softc.
- Use bus_foo rather than bus_space_foo and remove bus space tag and
handle from softc.
- The lpbb(4) driver just grabs Giant for now. This will be refined later
when ppbus(4) is locked.
- As was done with smbus earlier, move the DRIVER_MODULE() lines to match
the bus driver (either iicbus or iicbb) to the bridge driver into the
bridge drivers.
Tested by: sam (arm/ixp425)
|
|
|
|
|
|
| |
This fixes the cpu time being falsely reported as interrupt time.
MFC after: 3 days
|
|
|
|
|
|
| |
that could result in leaked ttys or a leaked pty + tty pair.
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
result in leaked tty structures.
- When constructing a new pty, allocate it's tty structure before adding
it to the list.
MFC after: 1 week
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add a mutex to the softc to protect the softc and device hardware.
- Use a private timer routine to drive the transmit watchdog timer instead
of using if_watchdog/if_timer.
- If if_alloc() fails during attach, fail the attach with an error rather
than panic'ing.
- Clear RUNNING and OACTIVE only in sncstop().
- Don't mess with IFF_UP.
- Don't leak 'struct ifnet' on detach.
- Setup interrupt handler after ether_ifattach().
- Call ether_ifdetach() rather than if_detach() in the pccard detach
routine.
Tested by: no one despite repeated requests
|
|
|
|
| |
MFC after: 1 day
|
|
|
|
|
|
|
|
|
|
|
|
| |
- let the loop iterate every page (as intended), and not some multiplies
(which led to a fake exhaustion of the ARM_NOCACHE_KVA_SIZE)
- eliminate using MIN(): it compared number of pages vs. address
(ARM_TP_ADDRESS), which was bogus
Reviewed by: cognet, imp
Obtained from: Piotr Ziecik kosmo ! semihalf dot com
MFC after: 3 days
|
|
|
|
|
|
| |
PR: kern/125261
Obtained from: OpenBSD
MFC after: 1 week
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
|
|
| |
PZERO + 1. The sleeping process at the priority <= PZERO is counted as
blocked, or, as comment states, 'disk wait'. PZERO + 1 works as well,
and does not cause user confusion.
Reported by: sam <samflanker at gmail com>
MFC after: 1 week
|
| |
|
|
|
|
|
|
| |
understand which code paths aren't possible.
Reported by: edwin
|
|
|
|
|
|
|
|
|
| |
commit, calling i386_parsedev(..., X, ...) where X is "ad", "bge", or
any other disk or network device name without a unit number, would
result in dereferencing whatever happened to be on the stack where the
variable "cp" is stored.
Found by: LLVM/Clang Static Checker
|
|
|
|
|
|
|
| |
this commit, sprintf("%s", "") could fail depending on what happened
to be on the stack.
Found by: LLVM/Clang Static Checker
|
|
|
|
|
|
|
|
|
| |
to this commit, "env BLOCKSIZE=4X df" prints not only "4X: unknown
blocksize" as expected, but sometimes also "maximum blocksize is 1G"
and "minimum blocksize is 512" depending on what happened to be on
the stack.
Found by: LLVM/Clang Static Checker
|
|
|
|
|
|
|
| |
stack>.
Found by: LLVM/Clang Static Checker
MFC after: 1 week
|
|
|
|
|
|
| |
more likely to have the right value. Remove superfluous assignments.
Found by: LLVM/Clang Static Checker
|
|
|
|
| |
highlighting work in vim.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
watchdog timeout issues and the root cause seems to stem from
silicon bug of controller. Personally I couldn't reproduce it on
RTL8169 controller but it seems it's dependent on usage pattern.
For newer PCIe based controllers I have no TSO complaints but
turning off TSO would be more safe. Users who are sure that
their controller works with TSO can still reenable the TSO with
ifconfig(8).
Reported by: Oliver Lehmann (lehmann at ans-netz dot de), Eugene Butusov (ebutusov at gmail dot com)
|
|
|
|
|
|
|
| |
11bits. This limits the maximum interface MTU size in TSO case
as upper stack should not generate TCP segments with MSS greater
than the limit. Armed with this information, disable TSO if
interface MTU is greater than the limit.
|
|
|
|
|
|
|
| |
understand which code paths aren't possible.
This commit eliminates 117 false positive bug reports of the form
"allocate memory; error out if pointer is NULL; use pointer".
|
|
|
|
|
|
| |
- ANSI'fy showrawquotas().
- Shut up GCC by initializing bgrace and igrace. The situation
that caused the GCC warning can never happen though.
|
|
|
|
|
|
|
|
|
| |
environ[0] to be more obvious that environ is not NULL before environ[0]
is tested. Although I believe the previous code worked, this change
improves code maintainability.
Reviewed by: ache
MFC after: 3 days
|
|
|
|
|
| |
PR: 125253
Submitted by: Mateusz Guzik <mjguzik@gmail.com> (original version)
|
|
|
|
|
| |
PR: 126223
Submitted by: Mateusz Guzik
|
|
|
|
|
|
|
|
|
| |
big endian platforms where time_t is 64bits (ie armeb and sparc64), it will
be a problem.
Use a temporary time_t to work around this.
Submitted by: Matthew Luckie <mjl AT luckie DOT org dot nz>
MFC after: 3 days
|
|
|
|
|
|
|
|
|
| |
assumed to be reviewd by them):
Stir directly from the kernel PRNG, without taking less random pid & time
bytes too (when it is possible).
The difference with OpenBSD code is that they have KERN_ARND sysctl for
that task, while we need to read /dev/random
|
|
|
|
| |
Spotted by: das
|
| |
|
|
|
|
|
|
|
| |
- Improve the order of some tests.
- Fix style.
Submitted by: bde
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lstat(2) is called on symlinks -- this code appears never to have
worked. The PR this addresses suggests that the intended
original behavior is the right one, but as bde points out in the
PR comments, we do actually support storing a mode on symlinks,
so returning it seems reasonable.
This is consistent with Mac OS X, which despite documentation to
the contrary does return the mode set on a symlink, but not some
other platforms. The Single Unix Spec requires only that the
returned bits be "meaningful", which seems at best unhelpful as
advice goes.
PR: 25018
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
| |
FreeBSD 7.1 before 8.0 ships.
Spotted by: Ulrich Spoerlein <uspoerlein at gmail dot com>
MFC after: 3 days
|
|
|
|
|
| |
Reviewed by: alc, Matt Dillon <dillon@apollo.backplane.com>
Approved by: alc
|
|
|
|
|
|
|
| |
FreeBSD 7.1 before 8.0 ships.
Spotted by: Ulrich Spoerlein <uspoerlein at gmail dot com>
MFC after: 3 days
|
|
|
|
| |
Approved by: imp
|
|
|
|
|
|
|
|
|
| |
vnode lock may cause a LOR between kld_sx lock and vnode lock.
linker_load_dependencies() drops kld_sx, and another thread may attempt
to load the same kld.
Reported and tested by: pjd
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As clearly mentioned on the mailing lists, there is a list of drivers
that have not been ported to the MPSAFE TTY layer yet. Remove them from
the kernel configuration files. This means people can now still use
these drivers if they explicitly put them in their kernel configuration
file, which is good.
People should keep in mind that after August 10, these drivers will not
work anymore. Even though owners of the hardware are capable of getting
these drivers working again, I will see if I can at least get them to a
compilable state (if time permits).
|
|
|
|
|
|
| |
PR: conf/126199
Submitted by: comet--berkeley (aka Pablo Picasso) <comet@transbay.net>
Approved by: bde@
|
|
|
|
| |
with no support for the LED, buttons, realtime clock or flash support.
|