r261266:
Add a jail parameter, allow.kmem, which lets jailed processes access
/dev/kmem and related devices (i.e. grants PRIV_IO and PRIV_KMEM_WRITE).
This in conjunction with changing the drm driver's permission check from
PRIV_DRIVER to PRIV_KMEM_WRITE will allow a jailed Xorg server.
/dev/kmem and related devices (i.e. grants PRIV_IO and PRIV_KMEM_WRITE).
This in conjunction with changing the drm driver's permission check from
PRIV_DRIVER to PRIV_KMEM_WRITE will allow a jailed Xorg server.
Submitted by: netchild
MFC after: 1 week
- Use system provided functions for HID report requests.
- Nice the mode setting, because the USB hardware does appear to
handle the commands right away.
MFC after: 1 week
the memory ranges that they decode for downstream devices rather than
creating ResourceProducer range resource entries. The result is that
we allocate the full range to the PCI root bridge device causing
allocations in child devices to all fail.
As a workaround, ignore any standard memory resources on a PCI root
bridge device. It is normal for a PCI root bridge to allocate an I/O
resource for the I/O ports used for PCI config access, but I have not
seen any PCI root bridges that legitimately allocate a memory resource.
Reviewed by: jkim
MFC after: 1 week
that all pressed keys are released before completing the USB keyboard
detach. This will prevent so-called "ghost-keys" from appearing after
that the USB device generating the key event(s) has been detached.
MFC after: 1 week
when activating an I/O or memory window on the CardBus bridge.
Tested by: Olivier Cochard-Labbe <olivier@cochard.me>
Reviewed by: imp
MFC after: 3 days
a timeout value of a single tick is given. With FreeBSD-10 and newer
the current system time is used as a starting point, and the minimum
callout time of a single tick will be guaranteed. This patch mostly
affect the DMA delay timeouts, which are typically in the range from
0.125 to 2ms.
MFC after: 1 week
- Store the length of each read-only VPD value since not all values are
guaranteed to be ASCII values (though most are).
- Add a new pciio ioctl to fetch VPD for a single PCI device. The values
are returned as a list of variable length records, one for the device
name and each keyword.
- Add a new -V flag to pciconf's list mode which displays VPD data for
each device.
MFC after: 1 week
console, it calls the grab functions. These functions should turn off
the RX interrupts, and any others that interfere. This makes mountroot
prompt work again. If there's more generalized need other than
prompting, many of these routines should be expanded to do those new
things.
Should have been part of r260889, but waasn't due to command line typo.
Reviewed by: bde (with reservations)
with USB device detach when using character device handles. This also
includes LibUSB. It turns out that "usb_close()" cannot always get a
reference to clean up its USB transfers and such, if called during the
kernel USB device detach.
Analysis by: hselasky @
Reported by: Juergen Lock <nox@jelal.kn-bremen.de>
MFC after: 1 week
add separate rx/tx ring indexes
add ring specifier in nm_open device name
netmap.c, netmap_vale.c
more consistent errno numbers
netmap_generic.c
correctly handle failure in registering interfaces.
tools/tools/netmap/
massive cleanup of the example programs
(a lot of common code is now in netmap_user.h.)
nm_util.[ch] are going away soon.
pcap.c will also go when i commit the native netmap support for libpcap.
non-modifier key press. This prevents so-called "ghost
keyboards" keeping modifier keys pressed while not
actually seen as a real keyboard.
MFC after: 2 weeks
found in High Speed USB HUBs which translate from High Speed USB into
FULL or LOW speed USB. In some rare cases SPLIT transactions might get
lost, which might leave the TT in an unknown state. Whenever we detect
such an error try to issue either a clear TT buffer request, or if
that is not possible reset the whole TT.
MFC after: 1 week
controller found in the MBP2013 has been observed to not work properly
unless this operation is performed.
MFC after: 1 week
Tested by: Huang Wen Hui <huanghwh@gmail.com>
make CAM to not try negotiate unsupported settings and suppress warnings.
While there, enable command queuing on pass-through devices, announced
in hba_inquiry, but disabled. Even though queue size is very small, It
seems working well enough.
Reviewed by: scottl
MFC after: 2 weeks
The origin of WEP comes from IEEE Std 802.11-1997 where it defines
whether the frame body of MAC frame has been encrypted using WEP
algorithm or not.
IEEE Std. 802.11-2007 changes WEP to Protected Frame, indicates
whether the frame is protected by a cryptographic encapsulation
algorithm.
Reviewed by: adrian, rpaulo
drivers and their firmware were under active development, but those days
have passed. The firmware now exists in pre-compiled form, no longer
dependent on it's sources or on aicasm. If you wish to rebuild the
firmware from source, the glue still exists under the 'make firmware'
target in sys/modules/aic7xxx.
This also fixes the problem introduced with r257777 et al with building
kernels the old fashioned way in sys/$arch/compile/$CONFIG when the
ahc/ahd drivers were included.
Remove old bits of data concat for 'ascii' field.
Remove special SIOCGIFSTATUS handling from if.c (which Coverity yells at).
Reported by: Coverity
Coverity CID: 1147174
MFC after: 2 weeks
WARNING: icl_pdu_check_data_digest: data digest check failed; got 0xf23b,
should be 0xdb7f23b
Tested by: Darcy Birkbeck
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
value. The "Intel Lynx Point" XHCI controller found in the MBP2013 has
been observed to not always set the event interrupt bit while there
are events to consume in the event ring.
MFC after: 1 week
Tested by: Huang Wen Hui <huanghwh@gmail.com>
the spoofed identify data into the user buffer rather than issuing the
command to the controller, since Chatham IDENTIFY data is always spoofed.
While here, fix a bug in the spoofed data for Chatham submission and
completion queue entry sizes.
Sponsored by: Intel
MFC after: 3 days
Most relevant features:
- netmap emulation on any NIC, even those without native netmap support.
On the ixgbe we have measured about 4Mpps/core/queue in this mode,
which is still a lot more than with sockets/bpf.
- seamless interconnection of VALE switch, NICs and host stack.
If you disable accelerations on your NIC (say em0)
ifconfig em0 -txcsum -txcsum
you can use the VALE switch to connect the NIC and the host stack:
vale-ctl -h valeXX:em0
allowing sharing the NIC with other netmap clients.
- THE USER API HAS SLIGHTLY CHANGED (head/cur/tail pointers
instead of pointers/count as before). This was unavoidable to support,
in the future, multiple threads operating on the same rings.
Netmap clients require very small source code changes to compile again.
On the plus side, the new API should be easier to understand
and the internals are a lot simpler.
The manual page has been updated extensively to reflect the current
features and give some examples.
This is the result of work of several people including Giuseppe Lettieri,
Vincenzo Maffione, Michio Honda and myself, and has been financially
supported by EU projects CHANGE and OPENLAB, from NetApp University
Research Fund, NEC, and of course the Universita` di Pisa.
freeing them.
The current code would walk the list and call the buffer free, which
didn't remove it from any lists before pushing it back on the free list.
Tested: AR9485, STA mode
Noticed by: dillon@apollo.dragonflybsd.org
related to setting up static device mappings. Since it was only used by
arm/mv/mv_pci.c, it's now just static functions within that file, plus
one public function that gets called only from arm/mv/mv_machdep.c.
obsolete. This involves the following pieces:
- Remove it entirely on PowerPC, where it is not used by MD code either
- Remove all references to machine/fdt.h in non-architecture-specific code
(aside from uart_cpu_fdt.c, shared by ARM and MIPS, and so is somewhat
non-arch-specific).
- Fix code relying on header pollution from machine/fdt.h includes
- Legacy fdtbus.c (still used on x86 FDT systems) now passes resource
requests to its parent (nexus). This allows x86 FDT devices to allocate
both memory and IO requests and removes the last notionally MI use of
fdtbus_bs_tag.
- On those architectures that retain a machine/fdt.h, unused bits like
FDT_MAP_IRQ and FDT_INTR_MAX have been removed.
static device mappings.
This SoC relied heavily on the fact that all devices were static-mapped
at a fixed address, and it (rather bogusly) used bus_space read and write
calls passing hard-coded virtual addresses instead of proper bus handles,
relying on the fact that the virtual addresses of the mappings were known
at compile time, and relying on the implementation details of arm
bus_space never changing. All such usage was replaced with calls to
bus_space_map() to obtain a proper bus handle for the read/write calls.
This required adjusting some of the #define values that map out hardware
registers, and some of them were renamed in the process to make it clear
which were defining absolute physical addresses and which were defining
offsets. (The ones that just define offsets don't appear to be referenced
and probably serve no value other than perhaps documentation.)
Using unmapped BIOs causes failure inside bus_dmamap_sync, since
this function requires valid MVA address, which is not present
if mapping is not set up.
Submitted by: Wojciech Macek <wma@semihalf.com>
Obtained from: Semihalf
Atmel boards I have.
# All Samsung, Toshiba and SanDisk parts will need to be in this table
# since they don't conform to the ONFI specification (they are all Toggle
# parts). There's some standards for the additional bytes so there's some hope
# to decode them automatically on a per-vendor basis, but even that has
# problems (and is what motivated the ONFI parameter page).
header is split out into its own BD for processing by the firmware. When
this split occurred the data length in the BD was not being set correctly
resulting in packet corruption.
Approved by: davidcd (mentor)
by receive code waiting for data digest even when the data segment was
empty. It didn't actually read it, but it waited until those four bytes
become available in the socket buffer, i.e. until any other PDU (such as NOP)
came in.
PR: kern/185240
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
- Nuke code setting PCI_POWERSTATE_D0; pci(4) already does that for type 0
devices.
- There's no need to keep track of resource IDs.
- Quiesce the interrupt before actually detaching.
- Use DEVMETHOD_END.
- Use NULL instead of 0 for pointers.
MFC after: 1 week
- Nuke code setting PCI_POWERSTATE_D0; pci(4) already does that for type 0
devices.
- Use PCIR_BAR instead of a homegrown macro.
- There's no need to keep track of resource IDs.
- Quiesce the interrupt before actually detaching.
- Use DEVMETHOD_END.
- Use NULL instead of 0 for pointers.
MFC after: 1 week
- Nuke code setting PCI_POWERSTATE_D0; pci(4) already does that for type 0
devices.
- Use PCIR_BAR instead of a homegrown macro.
- There's no need to keep track of resource IDs.
- Quiesce the interrupt before actually detaching.
- Use DEVMETHOD_END.
- Use NULL instead of 0 for pointers.
- Nuke dupe $FreeBSD$.
MFC after: 1 week
hw.ral.msi_disable (defaulting to using MSI).
- Probe with BUS_PROBE_DEFAULT instead of 0.
- Nuke code setting PCI_POWERSTATE_D0; pci(4) already does that for type 0
devices.
- Use PCIR_BAR instead of a homegrown macro.
- There's no need to keep track of resource IDs.
- Release resources again in case attaching fails.
- Quiesce the interrupt before detaching.
- Sprinkle const.
- Use DEVMETHOD_END.
- Use NULL instead of 0 for pointers.
- Trim headers.
- Nuke dupe $FreeBSD$.
MFC after: 1 week
- #if 0 the currently unused paired port linking and unlinking of dual
adapters.
- Simplify MSI/MSI-X allocation and release. For a single one, we don't need
to fiddle with the MSI/MSI-X count and pci_release_msi(9) is smart enough
to just do nothing in case of INTx.
- Canonicalize actions taken on attach failure and detach.
- Remove the remainder of incomplete support for older FreeBSD versions.
MFC after: 1 week
- Simplify MSI allocation and release. For a single one, we don't need to
fiddle with the MSI count and pci_release_msi(9) is smart enough to just
do nothing in case of INTx.
- Don't allocate MSI as RF_SHAREABLE.
- Use DEVMETHOD_END.
- Use NULL instead of 0 for pointers.
MFC after: 1 week
- Based on lessons learnt with dc(4) (see r185750), add bus space barriers to
the MII bitbang read and write functions as well as to instances of page
switching.
- Add missing locking to ed_ifmedia_{upd,sts}().
- Canonicalize some messages.
- Based on actual functionality, ED_TC5299J_MII_DIROUT should be rather named
ED_TC5299J_MII_DIRIN.
- Remove unused headers.
- Use DEVMETHOD_END.
- Use NULL instead of 0 for pointers.
MFC after: 1 week
fiddle with the MSI count and pci_release_msi(9) is smart enough to just
do nothing in case of INTx.
- Don't allocate MSI as RF_SHAREABLE.
MFC after: 1 week
better off living in aac_pci.c, but it doesn't seem worth creating a
aac_pci_detach() and it's also not the first PCI-specific bit in aac.c
MFC after: 3 days
This chip doesn't require the temperature sensor offset, either v1 or
v2. Doing so causes the initial calibration test to fail.
Tested:
* Intel Centrino 6150
by removing unsued file local functions and then unused callees.
A lot more warnings to resolve but someone had to break the ice.
MFC after: 10 days
X-Comment: I am not the new maintainer; chime in, it's ours.
o Forward termianl framebuffer ioctl to fbd.
o Forward terminal mmap request to fbd.
o Move inclusion of sys/conf.h to vt.h.
Sponsored by: The FreeBSD Foundation
The priority goes from "error" to "debug".
Connectors are polled every 10 seconds. Reading EDID is part of this
polling. However, when an invalid EDID is returned, this error message
is logged. When using Newcons for instance, having a kernel message
every 10 seconds is getting annoying.
Now that it's a debug message, it'll be logged only if hw.dri.debug is
enabled. This fix console spamming for some users.
Tested by: Larry Rosenman <ler@lerctr.org>
clients. Mask RX interrupts while grabbed on the atmel serial
driver. This UART interrupts every character. When interrupts are
enabled at the mountroot> prompt, this means the ISR eats the
characters. Rather than try to create a cooperative buffering system
for the low level kernel console, instead just mask out the ISR. For
NS8250 and decsendents this isn't needed, since interrupts only happen
after 14 or more characters (depending on the fifo settings). Plumb
such that these are optional so there's no change in behavior for all
the other UART clients. ddb worked on this platform because all
interrupts were disabled while it was running, so this problem wasn't
noticed. The mountroot> issue has been around for a very very long
time.
MFC after: 3 days
... for msleep/cv_*wait() return values, where wait_event*() is used
on Linux. ERESTARTSYS is the return code expected by callers when the
operation was interrupted.
For instance, this is the case of radeon_cs_ioctl() (radeon_cs.c): if
an error occurs, and the code isn't ERESTARTSYS (eg. EINTR), it logs an
error.
Note that ERESTARTSYS is defined as ERESTART, but this keeps callers'
code close to Linux.
Submitted by: avg@ (previous version)
Normal and bold fonts each have a glyph map for single or left half-
glyphs, and right half glyphs. The flag TF_CJK_RIGHT in term_char_t
requests the right half-glyph.
Reviewed by: ed@
Sponsored by: The FreeBSD Foundation
The previous code was checking the "VGA Enable" bit on the video card's
parent PCI-to-PCI bridge only. This didn't work for the case where the
video card is attached to the root PCI bus (ie. the card has no parent
PCI-to-PCI bridge).
Now, the new code:
1. checks the "VGA Enable" bit on the parent bridge only if it's a
PCI-to-PCI bridge;
2. always checks the "I/O" and "Memory address space decoding" bits
on the video card itself.
However, vendor-specific bits are not used.
This fixes the use of many integrated Radeon cards: without this patch,
we fail to detect them as the boot display and, when radeonkms looks for
the Video BIOS, it skips the shadow copy made by the System BIOS. It
then fails to fully initialize the card, because the shadow copy is the
only way to read the Video BIOS in these situations. A workaround was to
force the boot display selection using the "hw.pci.default_vgapci_unit"
tunable.
A previous version of this patch added a new function doing the checks.
Now, the vga_pci_is_boot_display() function is used to perform the
checks (only until the boot display is found) and return if the given
device is the boot display or not.
Furthermore, vga_pci_attach() logs "Boot video device" if the card being
attached it the Chosen One:
vgapci0: <VGA-compatible display> [...]
vgapci0: Boot video device
Reviewed by: kib@, jhb@ (both a previous version)
Tested by: lunatic_ (#freebsd-xorg, integrated Radeon card,
xmj (#freebsd-xorg, i915+NVIDIA cards)
Introduce a new formatting bit (TF_CJK_RIGHT) that is set when putting a
cell that is the right part of a CJK fullwidth character. This will
allow drivers like vt(9) to support fullwidth characters properly.
emaste@ has a patch to extend vt(9)'s font handling to increase the
number of Unicode -> glyph maps from 2 ({normal,bold)} to 4
({normal,bold} x {left,right}). This will need to use this formatting
bit to determine whether to draw the left or right glyph.
Reviewed by: emaste
using cpuid can be quirky (this is the case of VMWare without the
vPMC support) but fail to probe hwpmc.
o Apply the fix for XEON family of processors as established by
315338-020 document (bug AJ85).
Sponsored by: EMC / Isilon storage division
Reviewed by: fabient
Previously the code would just iterate over the whole tree as if it were
just a list.
Without this change I would observe X server becoming more and more
jerky over time.
MFC after: 5 days
in6addr_any and is not in the CLIP table either. This fixes a reported
TOE+IPv6 NULL-dereference panic in do_pass_open_rpl().
While here, stop creating hardware servers for any loopback address.
It's just a waste of server tids.
MFC after: 1 week
Some Intel XHCI controlles timeout processing so-called "TRBs" when
the final LINK TRB of a so-called "TD" has the CHAIN-BIT set.
MFC after: 1 week
Tested by: glebius @
o Assign sc->an_dev in an_probe() (which isn't really a probe function in
the standard newbus sense) as we may need it for printing errors.
o Use device_printf() rather than if_printf() in an_reset() - this is
called from an_probe() long before the ifp structure is initialised
in an_attach().
o Initialize the ifp structure early in an_attach() as we use if_printf()
in cases where allocation of descriptors etc fails.
MFC after: 3 days
them up as part of firmware initialization (which the driver gets to do
only if it's the master driver).
Read the range of tids available for the ETHOFLD functionality if it's
enabled.
New is_ftid() and is_etid() functions to test whether a tid falls within
the range of filter tids or ETHOFLD tids respectively.
MFC after: 2 weeks
receiving Zero Length Packets, ZLPs. See comment in code for more
information.
MFC after: 1 week
Reported by: Kohji Okuno <okuno.kohji@jp.panasonic.com>
sys/cdefs.h. In particular, in case of COMPAT_43, param.h includes
sys/types.h, which includes sys/select.h, which includes
sys/_sigset.h. The _sigset.h customizes the provided definions based
on COMPAT_43, eliminating osigset_t if symbol is not defined. The
sys/proc.h is included after opt_compat.h and needs osigset_t.
Move opt_compat.h inclusion into the right place.
Sponsored by: The FreeBSD Foundation
the bio is unmapped, so we must map the bio pages into pbuf. This
works around the geom classes which do not follow the MAXPHYS limit on
the i/o size, since such classes do not know about unmapped bios
either.
Reported by: Paolo Pinto <paolo.pinto@netasq.com>
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
inclusion of right after sys/param.h.
o Only vt_core module use compat options, move it from common header to module.
Reported by: Larry Rosenman ler at lerctr dot org
Sponsored by: The FreeBSD Foundation
o Include opt_splash.h for vt(9) to know when splash device is enabled.
o Build logo_freebsd.c only if splash and vt are enabled.
o Include opt_compat.h to know when we have to respect compatibility.
Sponsored by: The FreeBSD Foundation
The code was unmodified compared to Linux and returned the amount of
received bytes from the i2c bus. This led to non-working i2c bus and
failure to eg. read monitor's EDID, if connected to DisplayPort.
MFC after: 3 days
Tested by: Mikaël Urankar <mikael.urankar@gmail.com>
This fixes radeon_agp_init() and gtt_size is now correct. However, this
is not enough to make Radeon AGP cards work: ttm_agp_backend.c isn't
implemented yet.
Submitted by: tijl@
Make the scan state optional - we'll obviously need a vap, but we now
won't require the scan state. the only thing the scan state is needed
for is to check for the list of SSIDs to scan - which we can now
just plain ignore by passing in NULL as the scan state pointer.
Tested:
* Intel 5100 (STA)
This is in preparation for being able to use iwn_scan() to do an off
channel scan to reset the RF tuning.
It should be a no-op.
Tested:
* Intel 5100 (STA)
in preparation for the scan based retune logic.
The linux iwlwifi driver does a rescan (onto a non-active channel)
to force an RF retune when the PLCP error rates exceed a certain threshold.
* Add code to track HT PLCP rate errors;
* Separate out the PLCP error count fetch and update so the delta
can be used when checking for PLCP error rates;
* Implement the PLCP error logic from iwlwifi;
* For now, just print out whenever the error rate exceeds the
threshold.
The actual scan based retune will take a bit more effort; the scan
command code right now assumes that a scan state is passed in.
This does need to change to be more flexible (both for this and
in preparation for scanning multiple channels at once.)
Tested:
* 5100 (STA mode)
* 2200 (STA mode)
* 2230 (STA mode)
working on some RF tuning issues.
The linux iwlwifi driver has these thresholds which they use to see
if there are PLCP errors over a certain interval. If they hit this,
they trigger a single-channel (different from active channels!)
scan to retune the RF front-end.
- Add support to 40Gbps devices;
- Add support to control adaptive interrupt coalescing (AIC)
via sysctl;
- Improve support of BE3 devices;
Many thanks to Emulex for their continued support of FreeBSD.
Submitted by: Venkata Duvvuru <VenkatKumar.Duvvuru Emulex Com>
MFC after: 3 days
scheduling classes in the chip and to bind tx queue(s) to a scheduling
class respectively. These can be used for various kinds of tx traffic
throttling (to force selected tx queues to drain at a fixed Kbps rate,
or a % of the port's total bandwidth, or at a fixed pps rate, etc.).
Obtained from: Chelsio
for these chipsets.
* Correctly set the active/passive flag in the scan request - this is
NOT a "is the channel active|passive"; it's to do with whether we
have an SSID to actively scan for or not. The firmware takes care
of the active/passive setup of the channel.
* Calculate the active/passive dwell time based on the beacon interval
and the channel mode, rather than using a hard coded value.
* For now, hardcode the scan service_time. It's defined as:
31:22 - number of beacon intervals to come back onto the home channel
for;
0:21 - time (microseconds) to come back onto the home channel for.
When doing an active scan when the NIC is active (whether we're associated
or not - it only matters if we've setup the NIC to a destination or not)
this determines how much time to stay on the home channel for when
scanning. We can tune this based on the amount of active traffic.
For now it's 4 beacon intervals and 100 microseconds.
* Fix the "good crc threshold" setting. It differs based on the NIC
firmware. Some older firmware required a workaround; the later
firmware instead treats the field as a flag.
* Enforce that we are not sending a scan command if one is already
pending. Any time this is done is a bug and it absolutely needs
to be fixed - so be very loud.
* Add the SCAN flag to a few debug messages that are scan related but
only occuring under STATE.
Now, this does get noisy when you're scanning in an actively busy 2GHz
network as the firmware (for reason I don't quite yet understand) seems
hell bent on staying on some passive channels longer than it should.
However, it should eventually recover and complete the scan.
This is a work in progress; please let me know if things get stuck or
if things improve!
Tested:
* intel centrino 2200
* intel centrino 2230
* intel 6200
* intel 5100
* intel 4965 (gets upset, but that's a known issue)
Obtained from: linux iwlwifi
TX ring according to what the firmware requires.
The firmware requires A-MPDU sub-frames to be at a very specific ring
offset - that is, the ring slot offset should be (seqno % 256.)
This holds for every NIC I've tested thus far except the 4965,
which starts erroring out here shortly before the firmware panics.
Which is good, it's doing what it's supposed to (read: capture that
we've screwed up somewhere.)
The specifics about getting this stuff right:
* the initial seqno allocation should match up with the ringid.
* .. yes, this means we can start at a ring offset that isn't zero.
* .. because we program the start seqno in the firmware message
to setup the AC.
* The initial seqno allocation may be non-zero _and_ frames may be
being transmitted during a-mpdu negotiation. I faced similar
issues on ath(4) and had to software queue frames to that node+TID
during A-MPDU negotiation.
* seqno allocation should be in lockstep with ring increments.
* If we fail to transmit some segment, no, we shouldn't reuse that
ring slot. We should just transmit a BAR (which we aren't yet
doing, sigh) and move onto the next seqno.
* In theory there shouldn't be any holes in the seqno space when
we are transmitting frames.
Tested:
* 4965 (throws problems, so yes we have to fix this);
* 5100 (seems ok);
* 6200 (seems ok);
* 2200 (seems ok);
* 2230 (seems ok).
The directory sys/dev/drm2/i915 is apperently contributed code.
Revert to the broken version of this file to make future imports easier.
Requested by: kib
in /chosen, be ihandles. The ePAPR spec makes those cross-reference phandles,
since FDT has no concept of ihandles. Have the OF FDT CI module interpret
queries about ihandles as cross-reference phandles.
shifts into the sign bit. Instead use (1U << 31) which gets the
expected result.
This fix is not ideal as it assumes a 32 bit int, but does fix the issue
for most cases.
A similar change was made in OpenBSD.
Discussed with: -arch, rdivacky
Reviewed by: cperciva
In its stead use the Solaris / illumos approach of emulating '-' (dash)
in probe names with '__' (two consecutive underscores).
Reviewed by: markj
MFC after: 3 weeks
The code was easier to read without __DECONST and clang didn't report
any error. I thought the cast was enough...
MFC after: 3 days
X-MFC-With: r258549
drm_le_cmp() (qsort_r()'s callback) receives pointers to elements in the
array passed to qsort_r(), not the elements themselves.
Before this fix, the use of qsort_r() shuffled the array, not sorted it,
because the compare callback accessed random memory locations, not the
expected elements.
This bug triggered an infinite loop in KDE/xserver:
1. KDE has a kded module called "randrmonitor" which queries xserver
for current monitors at startup and then listens to RandR
notifications from xserver.
2. xserver handles the query from "randrmonitor" by polling the
video device using the "drm_mode_getconnector()" ioctl. This
ioctl returns a list of connectors and, for those with a
connected monitor, the available modes. Each modes list is sorted
by the kernel before returning. When xserver gets the connectors
list, it sorts the modes lists again.
In the case of this bug, when two modes are equal (in xserver's
compare function PoV), their order is kept stable (ie. the
kernel order is kept for those two modes). And because the list
was shuffled by the kernel, the order of two equal modes was
frequently changed in the final modes list in xserver.
3. xserver compares the returned connectors list with the list
obtained earlier. In particular, it compares the sorted
modes lists for each connector. If a property of a connector
changes (eg. modes), xserver sends a "RRNotify_OutputChange"
notification.
Because of the change of order between equal modes, xserver sent
a notification after each polling of the connectors.
4. "randrmonitor" receives a notification, triggered by its query. The
notification doesn't contain the new connectors list, therefore, it
asks for the new list using the same function: go back to step #2.
MFC after: 3 days
option, unbreak the lock tracing release semantic by embedding
calls to LOCKSTAT_PROFILE_RELEASE_LOCK() direclty in the inlined
version of the releasing functions for mutex, rwlock and sxlock.
Failing to do so skips the lockstat_probe_func invokation for
unlocking.
- As part of the LOCKSTAT support is inlined in mutex operation, for
kernel compiled without lock debugging options, potentially every
consumer must be compiled including opt_kdtrace.h.
Fix this by moving KDTRACE_HOOKS into opt_global.h and remove the
dependency by opt_kdtrace.h for all files, as now only KDTRACE_FRAMES
is linked there and it is only used as a compile-time stub [0].
[0] immediately shows some new bug as DTRACE-derived support for debug
in sfxge is broken and it was never really tested. As it was not
including correctly opt_kdtrace.h before it was never enabled so it
was kept broken for a while. Fix this by using a protection stub,
leaving sfxge driver authors the responsibility for fixing it
appropriately [1].
Sponsored by: EMC / Isilon storage division
Discussed with: rstone
[0] Reported by: rstone
[1] Discussed with: philip
big chunk of kernel memory. Validate size of data. Add error handling to
avoid calling copyout() when data has not been read correctly.
Reviewed by: zbb
Reported by: x90c <geinblues@gmail.com>
MFC after: 2 days
adapters. Both devices support Gigabit Ethernet and USB 2.0, and the AX88179
supports USB 3.0. The driver was written by kevlo@ and lwhsu@, with a few
bug fixes from me.
MFC after: 2 months
This fixes DPMS with KDE and radeonkms. Without this, the display would
freeze when the monitor is put into sleep state, and only resumes after
several dozens of minutes once the monitor is powered on again.
Tested by: Mathias Picker <Mathias.Picker@virtual-earth.de>
byte positions within the OOB area to support chips with unusual OOB
sizes such as 218 or 224 bytes.
The table for 128 byte OOB works for these but it assumes 3 bytes of ECC
per 256 byte block, and in the case of an ONFI chip the params page may
ask for something different. In other words, this is better but not
yet perfect.
to native endianness. We must also pay attention to unaligned accesses.
Copy the interesting parameters to a new struct so the rest of the code can
forget about these problems.
Submitted by: Kristof Provost <kristof@sigsegv.be> (cleanup) and me (orig).
The ONFI spec states that at least two bytes of the signature ("ONFI")
must be present, and the CRC must be correct to have a valid parameter
page. If the page is not valid there are at least two backup pages where
the data can also be found.
Submitted by: Kristof Provost <kristof@sigsegv.be> (cleanup) and me (orig).
Fixed various link related issues and 10GBaseT is now linking properly.
Modified the types for the driver tunables to be consistent with the sysctl APIs.
Approved by: davidch (mentor)
sys/dev/xen/balloon/balloon.c:
Remove unused and commented out code.
Fix deadlock caused by performing a sleepable malloc
while holding the balloon mutex.
Perform proper accounting of the memory used by the domain.
Submitted by: Roger Pau Monné
Sponsored by: Citrix Systems R&D
Reviewed by: gibbs
MFC after: 2 days
struct mbx_common_read_write_flashrom plus 32KB and caps the actual
transfer size at 32KB. This is harmless as it is but may confuse
static code analyzer, so allocate a full 32KB instead.
Reported by: Coverity via mjacob
Submitted by: Venkata Duvvuru <VenkatKumar.Duvvuru Emulex Com>
Coverity CID: 1125820
This field needs to be (a) set, and (b) greater than the other timeouts
(passive, active, maxquiet, etc.) It also is in microseconds, not
milliseconds.
I hope this will fix the scan hangs that people are seeing.
Obtained from: Linux iwlwifi
The previous code simply hard-coded IWN_ANT_AB which is only correct for
some of the NICs.
Now, if the NIC is a 1-stream TX, you need to set IWN_ANT_AB and _not_
just a single antenna. The Intel 5100 firmware panics the moment the
link quality table is updated.
So!
* no secondary antenna? Set it to IWN_ANT_AB;
* two-stream device? Transmit on the full transmit antenna configuration.
Tested:
* Intel 5100, STA
* Intel 2200 (eadler)
Obtained from: Linux iwlwifi
it can be overriden by its OFW/FDT version.
Give a chance for GPIO devices that implement the device_identify method to
attach.
Approved by: adrian (mentor)
