applications that use procfs on unionfs.
- Removed unionfs internal cache mechanism because it has
vfs_cache support instead. As a result, it just simplified code of
unionfs.
- Fixed kern/111262 issue.
Submitted by: Masanori Ozawa <ozawa@ongs.co.jp> (unionfs developer)
Reviewed by: jeff, kensmith
Approved by: re (kensmith)
MFC after: 1 week
make sure to never call sched_bind() for uninitialised CPUs.
Submitted by: Constantine A. Murenin <cnst@FreeBSD.org>
Sponsored by: Google Summer of Code 2007 (GSoC2007/cnst-sensors)
Mentored by: syrinx
Tested by: many
OKed by: kensmith
This commit includes the following core components:
* sample configuration file for sensorsd
* rc(8) script and glue code for sensorsd(8)
* sysctl(3) doc fixes for CTL_HW tree
* sysctl(3) documentation for hardware sensors
* sysctl(8) documentation for hardware sensors
* support for the sensor structure for sysctl(8)
* rc.conf(5) documentation for starting sensorsd(8)
* sensor_attach(9) et al documentation
* /sys/kern/kern_sensors.c
o sensor_attach(9) API for drivers to register ksensors
o sensor_task_register(9) API for the update task
o sysctl(3) glue code
o hw.sensors shadow tree for sysctl(8) internal magic
* <sys/sensors.h>
* HW_SENSORS definition for <sys/sysctl.h>
* sensors display for systat(1), including documentation
* sensorsd(8) and all applicable documentation
The userland part of the framework is entirely source-code
compatible with OpenBSD 4.1, 4.2 and -current as of today.
All sensor readings can be viewed with `sysctl hw.sensors`,
monitored in semi-realtime with `systat -sensors` and also
logged with `sensorsd`.
Submitted by: Constantine A. Murenin <cnst@FreeBSD.org>
Sponsored by: Google Summer of Code 2007 (GSoC2007/cnst-sensors)
Mentored by: syrinx
Tested by: many
OKed by: kensmith
Obtained from: OpenBSD (parts)
which is ukbd0. Specifically, the keyboard driver structures for ukbd0
are not allocated/freed but are statically allocated via a persistent
global variable. There is some additional magic for the ukbd0 such that
if the keyboard is marked as probed in this global variable, then we
don't check to see if the device_t we are probing has an interface.
This causes a problem if an attach of ukbd0 fails without fulling clearing
the state in the global variable. Specifically, if the keyboard fails to
initialize in init_keyboard() or kbd_register(), then the keyboard will
still be marked as probed. The USB layer will then try to offer the
"generic" version of the USB keyboard device (as opposed to the
per-interface sub-devices) and the ukbd(4) driver will see that the
keyboard is marked probe and will skip the "is this a per-interface device"
check. Later in ukbd_attach() it panics because it tries to dereference
the interface pointer which is NULL.
The fix is to clear the flags in the persistent keyboard data for ukbd0
when init_keyboard() or kbd_register() fail.
MFC after: 1 week
Reviewed by: imp
- Eliminate the hideous nfs_sndlock that serialized NFS/TCP request senders
thru the sndlock.
- Institute a new nfs_connectlock that serializes NFS/TCP reconnects. Add
logic to wait for pending request senders to finish sending before
reconnecting. Dial down the sb_timeo for NFS/TCP sockets to 1 sec.
- Break out the nfs xid manipulation under a new nfs xid lock, rather than
over loading the nfs request lock for this purpose.
- Fix some of the locking in nfs_request.
Many thanks to Kris Kennaway for his help with this and for initiating the
MP scaling analysis and work. Kris also tested this patch thorougly.
Approved by: re@ (Ken Smith)
on multiple different audit pipes. The old method used cv_signal()
which would result in only one thread being woken up after we
appended a record to it's queue. This resulted in un-timely wake-ups
when processing audit records real-time.
- Assign PSOCK priority to threads that have been sleeping on a read(2).
This is the same priority threads are woken up with when they select(2)
or poll(2). This yields fairness between various forms of sleep on
the audit pipes.
Obtained from: TrustedBSD Project
Discussed with: rwatson
MFC after: 1 week
This fixes the process portion of the bpf(4) stats if the peer forks
into the background after it's opened the descriptor. This bug
results in the following behavior for netstat -B:
# netstat -B
Pid Netif Flags Recv Drop Match Sblen Hblen Command
netstat: kern.proc.pid failed: No such process
78023 em0 p--s-- 2237404 43119 2237404 13986 0 ??????
MFC after: 1 week
- Add proper scanning support rather than letting the firmware grab the first
access point
- Overhaul state changes
- Use macros for locking and provide _locked() versions of some functions
- Increase debugging output
- Use a callout rather than the old watchdog interface
- Improve style, function names and defines
- Add WPA (TKIP) support
Based heavily on a patchset provided by Sam Leffler.
VR_STICKHW register would result in unexpected results on these
hardwares. wpaul said the following for the issue.
The vr_attach() routine unconditionally does this for all supported
chips:
/*
* Windows may put the chip in suspend mode when it
* shuts down. Be sure to kick it in the head to wake it
* up again.
*/
VR_CLRBIT(sc, VR_STICKHW, (VR_STICKHW_DS0|VR_STICKHW_DS1));
The problem is, the VR_STICKHW register is not valid on all Rhine
devices. The VT86C100A chip, which is present on the D-Link DFE-530TX
boards, doesn't support power management, and its register space is
only 128 bytes wide. The VR_STICKHW register offset falls outside this
range. This may go unnoticed in most scenarios, but if you happen to have
another PCI device in your system which is assigned the register
space immediately after that of the Rhine, the vr(4) driver will
incorrectly stomp it. In my case, the BIOS on my test board decided
to put the register space for my PRO/100 ethernet board right next
to the Rhine, and the Rhine driver ended up clobbering the IMR register
of the PRO/100 device. (Long story short: the board kept locking up on
boot. Took me the better part of the morning suss out why.)
The strictly correct thing to do would be to check the PCI config space
to make sure the device supports the power management capability and only
write to the VR_STICKHW register if it does.
Instead of inspecting chip revision numbers for the availability of
VR_STICKHW register, check the existence of power management capability
of the hardware as wpaul suggested.
Reported by: wpaul
Suggested by: wpaul
OK'ed by: jhb
1. The locking was changed to shared but roundrobin mode still updated a
pointer in the softc with the next tx interface to use. This will panic
under high load. Change this to an atomically incremented sequence number in
order to choose the tx port in round robin.
2. IFQ_HANDOFF will free the mbuf if the queue is full, this will then be freed
again by lagg_start() and panic. Reorganised the error handling and freeing
to fix this.
MFC after: 3 days
SAS-enabled cards. It also makes the driver MPSAFE, eliminating some
problems that resulted from CAM becoming MPSAFE. Many thanks to 3Ware/AMCC
for continuing to support FreeBSD.
Submitted by: Manjunath Ranganathaiah
Approved by: re
voltage of 0. This can result in a divide by zero trap. Add a guard
for this case. The value of lfcap is checked in acpi_battery_bif_valid()
just before this, so it is safe.
Reportd by: sam
Approved by: re
MFC after: 3 days
of directly from acpi0. Before it would attach prior to the sysresource
devices, causing the later allocation of its memory range to fail and
print a warning like "acpi0: reservation of fed00000, 1000 (3) failed".
Use an explicit define for our probe order base value of 10.
Help from: jhb
Tested by: Abdullah Ibn Hamad Al-Marri <almarrie / gmail.com>
MFC after: 3 days
Approved by: re
