| Age | Commit message (Collapse) | Author |
|---|
|
The ure_stop_task is not scheduled anywhere.
Compile tested here.
|
|
ok jsg
|
|
The printfs complaining about unknown FSB_FREQ values didn't end with
a newline. jsg points out that this is because the original i386 code
then prints MSR_EBL_CR_POWERON, which was omitted when the code was
adapted for amd64.
ok jsg
|
|
From Alex Deucher
bb65051dcd1fd380a73ca52c87f89522e15bf62d in linux 5.10.y/5.10.58
f2ad3accefc63e72e9932e141c21875cc04beec8 in mainline linux
|
|
From Matt Roper
7397034905acaecbc64f6838779bdc81667e682f in linux 5.10.y/5.10.58
9c9c6d0ab08acfe41c9f7efa72c4ad3f133a266b in mainline linux
|
|
From Shirish S
dd3f7c5c890450ab2ad6f269a3fdf7bcd6fc2908 in linux 5.10.y/5.10.58
0e99e960ce6d5ff586fc0733bc393c087f52c27b in mainline linux
|
|
directly after having successfully associated. In that case we should
ignore the message, because otherwise we re-scan, re-associate and then
get stuck in a loop. Ignoring the unsolicited assoc status even leads
to a successful connection.
Found by and ok gerhard@
|
|
reminded by brynet
|
|
This makes modifying hw.setperf and apmd -A work on robert's laptop.
Previously, it would sometimes be impossible to set hw.setperf to any
value on this machine.
Keep a delay loop that waits for the MSR write to take effect before
setting hw.cpuspeed to the new value since this is apparently needed
for some pre-ryzen processors.
Debugging, initial diff & test by robert
ok brynet
|
|
frequencies on intel processors. This way, the default hw.setperf=99
corresponds to the maximum ordinary speed while setting it to 100
enables turbo mode.
Tested in snaps for a week, positive feedback from several.
|
|
problems with suspend on various ThinkPad machines seen by me, tb@, deraadt@,
benno@ seem to go away with this reverted.
|
|
From Nicholas Kazlauskas
98b070694f4570908a0e8ea5afb68d81b0aa2051 in linux 5.10.y/5.10.57
d7940911fc0754d99b208f0e3098762d39f403a0 in mainline linux
|
|
From Victor Lu
f9d875c8c92f1bdaeeb3eeccbf8402974f20cd31 in linux 5.10.y/5.10.57
ec3102dc6b36c692104c4a0546d4119de59a3bc1 in mainline linux
|
|
From Jason Ekstrand
118b070bf415eb6c0fa39e5fa1b1ef6b83e80cee in linux 5.10.y/5.10.57
3761baae908a7b5012be08d70fa553cc2eb82305 in mainline linux
|
|
The backport of c9d9fdbc108af8915d3f497bbdf3898bf8f321b8 to 5.10 in
6976f3cf34a1a8b791c048bbaa411ebfe48666b1 removed more than it should
have leading to 'batch' being used uninitialised. The 5.13 backport and
the mainline commit did not remove the portion this patch adds back.
Sent to the linux stable list and queued to be in 5.10.58.
|
|
From Jason Ekstrand
6976f3cf34a1a8b791c048bbaa411ebfe48666b1 in linux 5.10.y/5.10.57
c9d9fdbc108af8915d3f497bbdf3898bf8f321b8 in mainline linux
|
|
ok gnezdo@
|
|
with James Hastings
|
|
Set the pointer to all 1s as linux do.
OK patrick@
|
|
The sending machine is doing zero window probes, but is not sending
any more data although the other machine announced that it has space
again. The header prediction code did not update snd_wl2. If there
was a sequence number wrap, the send window update block is not
reached.
Update snd_wl2 when receiving predicted ACKs and and update snd_wl1
and rcv_up for predicted pure data.
from FreeBSD; OK sashan@ claudio@
|
|
|
|
don't do anything on shutdown.
This fixes a panic that was reported by me on X1 Extreme Gen 1.
ok ratchov@
|
|
opened exclusively, and the flags argument is passed to usbd_setup_xfer().
USBD_EXCLUSIVE_USE has the same value as USBD_NO_COPY, which means that
data transferred would not be copied to the buffer where the driver expects
it.
None of these drivers actually used the interrupt data for anything, and
in some the interrupt pipe code was #if 0'd out, so this doesn't change
anything, but fixing this up prevents unwary developers like me from
copying code that doesn't work.
ok mglocker@
|
|
to find the VBT
ok jsg
|
|
This driver does not need to allocate a DMA segment for the Tx scheduler.
Instead this driver uses the scheduler byte count array which is allocated
per Tx ring. Remove sc->sched_dma and related code inherited from iwm(4).
Patch by zxystd from OpenIntelWireless.
|
|
prompted by jcs@ reporting a protection fault trap in
drm_mode_rmfb_work_fn() while playing a youtube video in firefox on a
kaby lake machine. He later saw the same trace on tiger lake.
The arguments to drm_mode_rmfb_work_fn() are on the stack in
drm_mode_rmfb() with flush_work() called before return.
taskq_barrier() is only a barrier for running not queued tasks.
I suspect the linux functions expect any previously queued work to
complete not just any currently running work. I'm not sure if the
difference matters in practice.
|
|
This fixes a panic that was reported on misc@ and bugs@ by
Mike <the.lists () mgm51 ! com> and
Anindya Mukherjee <anindya49 () hotmail ! com>
OK jcs@, thanks to mpi@/jcs@ for the pointers!
|
|
re-initialized, otherwise TX/RX keeps disabled. Fixes the issue on the
RTL8153/B devices, but unfortunately not on the RTL8152 devices. I have
no RTL8152 device available.
Tested by a few on RTL8153/B devices.
ok sthen@
|
|
fixing an mbuf leak way with wgpka (keepalive) found the hard way by Matt P.
Diff from Matt Dunwoodie, ok claudio@
|
|
From Jiri Kosina
fc2756cce06f9833ebabd309b5b5080ed5c56897 in linux 5.10.y/5.10.56
d47255d3f87338164762ac56df1f28d751e27246 in mainline linux
|
|
From Jiri Kosina
ccc7a1bb322e4169b738aa3fc8b5dfcfefdacb37 in linux 5.10.y/5.10.56
6aade587d329ebe88319dfdb8e8c7b6aede80417 in mainline linux
|
|
From Dale Zhao
63570e578094b4f0b6b8c6ac4a68195455733e31 in linux 5.10.y/5.10.56
b53e041d8e4308f7324999398aec092dbcb130f5 in mainline linux
|
|
relies upon this; sparc64 turned out to be the only platform where this
was not the case.
help, diff, and commit message from Miod Vallat
"makes sense" kettenis@
|
|
The preceding trunk_link_active() already produced RTM_IFINFO message when
trunk(4) state was changed. I such case we double RTM_IFINFO message or we
produce false message when trunk(4) state was not changed.
ok florian@
|
|
FENCE.I instruction on the remote harts. According to the RISC-V
ISA documentation this is necessary to make remote harts observe earlier
stores. Also issue the local FENCE.I first; this is what both FreeBSD and
Linux does. Seems to fix at least some of the issue we've seen running
GENERIC.MP on MP machines.
ok jca@
|
|
so simply look up the first clock instead of looking for a specific one by
name. Allows rkpwm(4) to find the clock when using a recent device tree.
From Tomasz Bielecki
ok kettenis@
|
|
"makes perfect sense to me" chris
ok gnezdo jca
|
|
|
|
|
|
From Zheyu Ma
5c3d753b872a706af9317fef4edfb6b640d8a71e in linux 5.10.y/5.10.55
9e5c772954406829e928dbe59891d08938ead04b in mainline linux
|
|
framebuffer when Backspace is typed.
Reading data from LUNA framebuffer's 'common write plane' is not
valid. But on 1bpp framebuffer routine attempts to read from common
write plane in macro. That causes displaying incorrect patterns.
This bug was found on nono's LUNA-88K emulation first, then inspected
on the real hardware after I fortunately got 1bpp framebuffer.
Spotted and investigated by Isaki and Sugahara of nono procject.
Tested on my LUNA-88K2.
|
|
|
|
e.g. uvideo(4) with lower resolutions.
In general we might need to re-write parts of the nframes handling in the
driver, since the NetBSD nframes transfer allocation doesn't match with our
USB stack.
With this we can at least start further testing and improvement for ISOC
support.
|
|
Starting with major version 35 the Linux driver prints the minor version
number in hexadecimal.
Same change was made for iwm(4) in CVS commit LCM6R5u9jeF8bcXB
|
|
This allocation was left over from code inherited from iwm(4) where
it is used for transferring firmware code to the device. Devices
supported by iwx(4) use an entirely different mechanism for loading
firmware and don't need this allocation at all.
Based on a patch by zxystd from the OpenIntelWireless project.
|
|
clobber in the inline assembly.
|
|
|
|
recently updated code. There, sync the hardware specific parts with the
NetBSD driver.
|
|
|
|
|
