| Age | Commit message (Collapse) | Author |
|---|
|
optional and will only be compiled for amd64/i386. Apparently this is
only needed on Raven Ridge APUs.
ok jsg@, patrick@, deraadt@
|
|
|
|
was output in the pane faster than the timer would fire, so change how
it works to only defer the timer again if the pane was actually resized
within the last timer period. Reported by James Tai in GitHub issue
1880.
|
|
SoCs. For now only a limited set of GPIO pins on the G12A/G12B variants
are supported.
ok patrick@
|
|
ok patrick@
|
|
|
|
this has been in snaps for the last week without issue, and has
been running in production on a bunch of my boxes for a week before
that, also without issue.
|
|
|
|
shrinks some QSFP+ DAC output a bit.
|
|
|
|
qsfp and xfp have remarkably similar layouts, so we can use the
same code to print media for both. sfp and xfp/qsfp generally have
the same fields, just in different register locations and with some
different scales/factors for some values. this change provides a
map of these differences as structs for the sfp and qsfp/xfp layouts.
the big difference between sfp, xfp, and qsfp that still remains
is how they interpret the wavelength field. qsfp stores either optic
wavelength in units of 0.05nm, or a couple of copper cable attenuation
values in dB at different frequencies. sfp stores wavelength in nm
units, but has magic values to blacklist copper cables with. xfp
stores wavelength in 0.05 nm units, so more like like qsfp. right
now the code uses the sfp behaviour, which means qsfp will show a
weird wavelength for copper cables when it shouldnt. i'm still
trying to figure out the least worst way to handle that, but at
least it looks right for optics now.
|
|
this shows the maximum case temperature reported by the chip, and
the low and high alarm ranges for temp and vcc when page 3 is
available and working.
this will hopefully give deraadt@ a better idea about how much
headroom one of his 100g optics has.
|
|
msr/pat, clock-startup, firmware upgrade, fpu initialization, and cpu
soft-state initialization in the same order. That kind of chaos is
crazy and fragile. Improve the acpi resume call sequence and unify order
of the operations.
|
|
|
|
|
|
arp(8) already has a common getinetaddr() but it ignores -n for delete() and
uses gethostbyname(3), so simply replace it with parse_host() from ndp.c
instead of changing behaviour around the old API.
In set(), make host[] and eaddr[] const since all functions receiving those
variables as parameters expect const anyway.
OK bluhm
|
|
Zap obsolete linter comments while here.
No object change;
OK bluhm
|
|
OK sthen@, pea@
|
|
actually testing them.
|
|
|
|
|
|
|
|
|
|
|
|
wiping the entire cache every time a scan is triggered.
This has benefits for userland programs trying to look at scan results,
and for drivers which don't get a full view from hardware on every scan.
Nodes will still be evicted from the cache in one of several ways:
Add a new way of timing out inactive nodes which don't send a beacon
within 10 scan iterations, for client mode only. This should get rid
of stale APs if we're scanning for some time in a changing environment.
If we fail to associate a few times, the corresponding node is removed.
If net80211 transitions back to INIT state (e.g. because of a
user-initiated configuration change) all nodes are removed.
When a background scan starts all nodes will be removed. This could be
revisited later but has been intentionally left as-is for now.
Tested by myself, jmc@, benno@, procter@ on iwm(4), athn(4) and ral(4).
|
|
scsi_probe() and make scsi_probe_bus(), scsi_probe_target() and
scsi_probe_lun() simple wrappers around scsi_probe().
Abstract the determination of which luns to probe into a separate
function. Thus eliminating the need to remove/add lun 0 link while
probing devices modern enough to support REPORTLUNS. Which means the
lun 0 link is no longer in different positions in the scsi_link list
for such devices compared to older devices which are blindly probed
until an invalid LUN is encountered.
|
|
|
|
the i.MX8M SoCs.
ok kettenis@
|
|
this is a bit rough, but a good start. apart from the media types
and length, qsfp support should be on par with sfp modules now.
|
|
so check whether a notifier is on the list before trying to remove it.
Fixes a crash found by semarie@.
ok semarie@
|
|
|
|
|
|
|
|
|
|
|
|
a tiny number of clocks for the G12A/B families only.
ok jsg@
|
|
|
|
there are some extremely terrible modules out there that violate
specs badly. some SFP+ DACs i have don't support page switching,
and always report page 0xff. let userland look at them anyway.
|
|
problem found by and this fix was tested by groos at xiplink dot com
on bugs@
|
|
basically the "read phy register" admin op uses the "address" field
on SFP modules for the i2c address, but uses that same field for
the "sff page number" for QSFP. this wraps the calls to the admin
op with sfp and qsfp specific code, and chooses between them depending
on what type of phy the fw reports.
tested by me and jmatthew@ pretty hard
|
|
i have some qsfp DACs and a couple of optics, and they're all
terrible, so this is about as far as i can go for now. at least the
code will be robust in the face of terrible modules though.
the DACs are pretty dumb and basically report that they're DACs
with some strings. this code just prints that they're DACs with
strings now.
modules are supposed to be able to report overall temperature and
voltage, and optics can report tx and rx values for the 4 different
signal lanes they're supposed to provide. interestingly the current
values are always reported in the lower page, but thresholds are
reported in page 3, but not all modules support page switching.
devices are supposed to say whether they can switch pages, but i
have one that does say it can switch but then doesn't. anyway, the
take away is that it is therefore possible for a module to report
values without also
reporting thresholds.
this sets the code up to report the values on their own if we can't
query page 3 for any reason.
if the temp sensor value looks bogus (ie, 0x0000 or 0xffff), assume
the monitor values are bogus and bail early.
hopefully i can find a module soon that supports multiple signal
lanes and actually reports their values and thresholds for them.
|
|
read sequentially anyway, (hash-sized) block by block. This avoids
counting potentially large files against the memory limits of the
process. Problem reported by Jan Stary, thanks.
ok deraadt@
|
|
|
|
ensure that any other thread currently trying to acquire the underlying
vnode lock has observed that the same vnode is about to be exclusively
locked. Such threads must then sleep until the exclusive lock has been
released and then try to acquire the lock again. Otherwise, exclusive
access to the vnode cannot be guaranteed.
Thanks to naddy@ and visa@ for testing; ok visa@
Reported-by: syzbot+374d0e7e2400004957f7@syzkaller.appspotmail.com
|
|
The fix is the same as for other parse.y files in the tree (see bgpd(8) or
unwind(8))
ok bluhm@
|
|
OK florian
|
|
Handle the ECN in the fragment queue.
Reported-by: syzbot+0aa80b25e9041001cac8@syzkaller.appspotmail.com
fix from FreeBSD; OK claudio@
|
|
ok patrick@
|
|
|
|
OK gerhard@
|
