| Age | Commit message (Collapse) | Author |
|---|
|
|
|
ok miod@
|
|
ok kettenis@
|
|
No objection from kettenis@
|
|
|
|
and iir in the physical trap save area and copy into the trap frame once
back in virtual.
ok kettenis@
|
|
ok mikeb@ fries@ mpf@ henning@ dlg@ matthew@
|
|
Synchronization operations are expressed from the perspective of the host
RAM, e.g., a device -> memory operation is a READ and a memory -> device
operation is a WRITE.
the status block that the isr reads is written to by the device.
the chip writes to memory, it is therefore a READ.
this also adds the preread sync when the map is set up and the postread
sync when the map is torn down for better symmetry. there are probably
more issues like this in the code, but this is a start.
discovered while discussing another diff with claudio@
|
|
Additional testing by jasper@ and pea@
|
|
|
|
rather than looping over them until it runs out of work to do.
looping in the isr is bad for several reasons:
firstly, the chip does interrupt mitigation so you have a
decent/predictable amount of work to do in the isr. your first loop
will do that chunk of work (ie, it pulls off 50ish packets), and
then the successive looping aggressively pull one or two packets
off the rx ring. these extra loops work against the benefit that
interrupt mitigation provides.
bus space reads are slow. we should avoid doing them where possible
(but we should always do them when necessary).
doing the loop 5 times per isr works against the mclgeti semantics.
it knows a nic is busy and therefore needs more rx descriptors by
watching to see when the nic uses all of its descriptors between
interrupts. if we're aggressively pulling packets off by looping
in the isr then we're skewing this check.
ok deraadt@ claudio@
this is like src/sys/dev/pci/if_ix.c r1.50.
|
|
than looping over them until it runs out of work to do.
in my testing i have found that under what i consider high pps
(>160kpps) ix would loop 4 or 5 times in the interrupt handler,
where each loop does a bus_space_read and the mclgeti loop (ie, rx
dequeue followed by rx ring fill).
looping in the isr is bad for several reasons:
firstly, the chip does interrupt mitigation so you have a
decent/predictable amount of work to do in the isr. your first loop
will do that chunk of work (ie, it pulls off 50ish packets), and
then the successive looping aggressively pull one or two packets
off the rx ring. these extra loops work against the benefit that
interrupt mitigation provides.
bus space reads are slow. we should avoid doing them where possible
(but we should always do them when necessary).
doing the loop 5 times per isr works against the mclgeti semantics.
it knows a nic is busy and therefore needs more rx descriptors by
watching to see when the nic uses all of its descriptors between
interrupts. if we're aggressively pulling packets off by looping
in the isr then we're skewing this check.
ok deraadt@ claudio@
testing by phessler@ bluhm@ and me in production
|
|
|
|
|
|
|
|
|
|
some broken intel chipsets that require longer delays, we will cope with
that later hopefully.
ok kettenis
|
|
to possibly favor the mirror instead of the main ccd by incorrectly
considering the main ccd is in the failure state, for interleaved+mirrored
ccds.
ok deraadt@
|
|
thus possibly consuming all of our available kva mapping buffers for
deps. Diff and analysis actually comes from Pedro Martelleto (thanks!)
tested by me and thib
ok thib@, art@
|
|
of a connection originator. this allows one to query the source rdomain
with a SO_RTABLE socket option. figured out with reyk, ok claudio.
|
|
Discovered, narrowed down, and tested by jmc@.
"definitely commit that" deraadt@, ok miod@
|
|
defined in all of uipc_mbuf.c. I use this function a lot for quick
printf debugging.
|
|
means the data size of a frame can be calculated if the dimensions
are known.
* calculate frame data sizes for uncompressed formats instead of believing
what the hardware says. the UVC spec changed between 1.0 and 1.1, and
as a result, some devices return bogus information.
* skip under-sized as well as over-sized uncompressed frames; there is
only one correct size for uncompressed frames.
* remove quirk to fix uncompressed frame sizes on certain devices,
since that now always happens.
* check that the device is actually using the parameters we think it's
using.
|
|
got broken. Most /usr/src/regress/sys/kern/splice/args-oobinline-*
regression tests fail when they split an mbuf at out-of-band data.
ok claudio@, deraadt@
|
|
Pluses:
- Add support SMBus for VT82C596, VT82C596B, VT82C686A, VT8231
- Add support ACPI timer for all VIA South Bridges
ok deraadt@, tested sthen@
|
|
with broadcast packets.
|
|
|
|
detach happens after the hardware is gone, so don't try to touch
the hardware in the detach path
but azalia_pci_detach is called if the device coiuld not be initialized.
in that case, shut the hardware down.
|
|
addresses >4GB to 64-bit BARs have started to appear. But as long as machines
still support running 32-bit operating systems we don't expect to see BARs
that aren't addressable using PAE. Fixes a panic reported by william@.
ok deraadt@
|
|
|
|
|
|
|
|
|
|
and the problem isn't obvious yet.
|
|
|
|
autoconf how to find the spmath files.
|
|
value when this isn't possible in practice, use a 32 bit value.
ok kettenis@ miod@ oga@
|
|
integer zero is intended.
|
|
ok deraadt
|
|
o350 to boot once again
ok miod
|
|
|
|
is 0.
ok deraadt.
|
|
by claudio to be related to this commit) until jakemsr has time to fix it
|
|
|
|
|
|
handling of recursive IPComp payloads. (This code is way old and may
go away soon in favor of using sys/lib/libz, but committing anyway as
plans aren't finalized yet.)
ok deraadt@
|
|
prompted by deraadt
|
|
prodded and ok deraadt
|
|
print the "sdN:" at the start of the now empty line. Noted by
miod@.
|
|
the equivalent i386 file
ok kettenis@ deraadt@
|
