there's a 1-element long array and a loop conditional that tries to see
if indexes for it are not identical. as these indexes will always both
be 0, the only valid index, the condition is always false. GCC 12
triggers a strange warning on this code that can never run (see below),
so simply assert the array size is 1 and comment the rest.
amdgpu_dc_stream.c:470:55: error: array subscript [0, 0] is outside array bounds of 'struct dc_writeback_info[1]' [-Werror=array-bounds]
470 | stream->writeback_info[j] = stream->writeback_info[i];
This driver is not built-in by default, thus loadable module can help (un)lucky
owners of 64-bit capable VIA (Nano/Eden) systems or early AMD/Intel systems
with some VIA chipsets, which include VIA integrated graphics.
I also boldly added product IDs for few later models from VX8xx/VX9xx chipsets
without 3D support (DX9_0) to "expand" the driver support to more systems.
Tested successfully basic functionality on VX800, and partially successfully
on VX900 (on VX900 Xorg failed to initialize due to openchrome related issues,
viadrmums attaches and it is by used the driver).
Didn't test on VX855, I don't have one.
Pull up to netbsd-10 is needed.
most of these are like, eg
void foo(int[2]);
with either of these
void foo(int*) { ... }
void foo(int[]) { ... }
in some cases (such as stat or utimes* calls found in our header files),
we now match standard definition from opengroup.
found by GCC 12.
If cv_wait_sig returns because a signal is delivered, we may
nonetheless have been granted the lock. It is harmless for us to
ignore this fact in three of the four paths, but in
ww_mutex_state_wait_sig, we may now have ownership of the lock and
MUST NOT return failure because the caller MUST release the lock
before destroying the ww_acquire_ctx.
While here, restructure the other three loops for clarity, so they
match the structure of the fourth and so they have a little less
impenetrable negation.
PR kern/57537
XXX pullup-8
XXX pullup-9
XXX pullup-10
This way they are computed -- using FP instructions -- before
DC_FP_END, after which point FP instructions will trap or behave
unpredictably.
This is a workaround, not a proper solution -- really, the
DC_FP_START/END calls should happen in a separate compilation unit
built without -mhard-float or whatever, but that's a lot more work to
make happen for now.
PR kern/57059
XXX pullup-10
drm_sched_init() is not called for these rings, and we'd panic trying
to mutex_destroy() a mutex that wasn't initialised.
this seems like a general bug, not a bug in netbsd port.
Use ${CC_WNO_MAYBE_UNINITIALIZED} instead of
the older style more complex expressions.
Remove workarounds if they were for a specific
version of gcc < 10.
this is the same change as nouveau_pci.c:1.37, and should fix at
least PR#56714 and i thought at least another PR i can't find right
now. it fixes at least 2 different radeon cards for me on UEFI
booted system.
XXX: pullup-10 also include the original change:
http://mail-index.netbsd.org/source-changes/2023/03/01/msg143606.html
Under the scenario with a packet with length of 67 bytes, a header length
using the default of 20 bytes and a TCP data offset (th_off) of 48 will
cause m_pullup() to fail to make sure bytes are arranged contiguously.
m_pullup() will free the mbuf chain and return a null. ipfilter stores
the resultant mbuf address (or the resulting NULL) in its fr_info_t
structure. Unfortunately the erroneous packet is not flagged for drop.
From FreeBSD via CY Schubert; originally reported by: Robert Morris
<rtm at lcs.mit.edu>
20 October 2022. Summary of changes for version 20221020:
This release is available at https://acpica.org/downloads
0) Global changes:
Allow disabling of -Werror. For distro maintainers having `-Werror`
can delay update of GCC. Since every GCC release might add new
warnings that were not yet captured, it might break the build of
packages. With this change, distros can now build with `NOWERROR=TRUE`
instead of patching either the errors or the makefiles. The default
behavior keeps on using `-Werror`.
1) ACPICA kernel-resident subsystem:
Added support for FFH Operation Region special context data.
FFH(Fixed Function Hardware) Opregion is approved to be added in
ACPI 6.5 via code first approach[1]. It requires special context
data similar to GPIO and Generic Serial Bus as it needs to know
platform specific offset and length.
Reverted this commit "executer/exsystem: Warn about sleeps greater
than 10 ms." Due to user complaints about valid sleeps greater than
10ms seen in some existing machines -- generating lots of warnings.
Do not touch VGA memory when EBDA < 1KiB. The ACPICA code assumes
that EBDA region must be at least 1KiB in size. Because this is
not guaranteed, it might happen that while scanning the memory for
RSDP pointer, the kernel touches memory above 640KiB. This is
unwanted as the VGA memory range may not be decoded or even present
when running under virtualization.
Check that EBDA pointer is in valid memory. If the memory at 0x40e
is uninitialized, the retrieved physical memory address of EBDA
may be beyond the low memory (i.e. above 640K). If so, the kernel
may unintentionally access the VGA memory, that might not be decoded
or even present in case of virtualization.
2) iASL Compiler/Disassembler and ACPICA tools:
Completed the existing partial support for the CDAT "table". Although
this isn't technically an ACPI table (It doesn't go into the XSDT),
it is possible to support this table in the Data Table compiler.
Created one new file, "utilities/utcksum.c", used to centralize
checksum generation/validation into one location. Includes changes
to makefiles and MSVC project files.
Updated support for the IORT table - update to version E.e
Added CXL 3.0 structures (CXIMS & RDPAS) to the CEDT table
iASL: Added CCEL table to both compiler/disassembler.
iASL: NHLT table: Fixed compilation of optional undocumented fields
iASL: Fix iASL compile error due to ACPI_TDEL_OFFSET. Commit #
10e4763 ("iASL: Add CCEL table to both compiler/disassembler")
introduced the iASL build issue. The issue is due to using
ACPI_TDEL_OFFSET for CCEL table member reference. To fix it, change
ACPI_TDEL_OFFSET with ACPI_CCEL_OFFSET.
acpica 20220331 introduced the following change:
For the ASL Sleep() operator, issue a warning if the sleep value is
greater than 10 Milliseconds. Quick boottime is important, so warn about
sleeps greater than 10 ms. Distribution Linux kernels reach initrd in 350
ms, so excessive delays should be called out. 10 ms is chosen randomly,
but three of such delays would already make up ten percent of the
boottime.
This can generate many console messages like:
[ 26.055036] ACPI Warning: Firmware issue: Excessive sleep time (0x0000000000000064 ms > 10 ms) in ACPI Control Method (20220331/exsystem-239)
(60 of them in the latest boot on one older Ivy Bridge laptop.)
This has been reverted upstream and is not present in the next release.
df896f452f
(Also previously reverted in FreeBSD and Linux.)
This can be included unconditionally, and db_active can then be
queried unconditionally; if DDB is not in the kernel, then db_active
is a constant zero. Reduces need for #include opt_ddb.h, #ifdef DDB.
mrg