Update to Linux v6.6 drivers #283

wulf7 · 2024-01-29T23:22:28Z

Status:

Both Intel and AMD generally works. Tested on SkyLake, TigerLake, AlderLake, AMD780M, 7600M and GreenSardine

What is not done yet:

Intel DG2 GUC/HUC support. Depends on MEI driver (not ported yet) and PXP
Intel PXP. Depends on aggregate driver support
AMD NUMA
folio support

It is required to specify full path to linuxkpi_video.ko module as it conflicts with system one. This may be done e.g. with addition of following lines to rc.conf:
kld_list="/boot/modules/linuxkpi_video.ko /boot/modules/i915kms.ko"
for i915kms or
kld_list="/boot/modules/linuxkpi_video.ko /boot/modules/amdgpu.ko"
for amdgpu

evadot · 2024-06-27T06:03:16Z

I think that all the linuxkpi patches are in -CURRENT now ?
What's the status of suspend/resume, iirc @emaste said he had problems on a intel laptop with this branch (while it worked with 6.1) ?

wulf7 · 2024-07-02T23:47:44Z

I think that all the linuxkpi patches are in -CURRENT now ?

I placed a bunch of remaining patches to phabricator just now. Except pci_iomap_range one which requires reworking to get proper meteorlake+ support.

What's the status of suspend/resume, iirc @emaste said he had problems on a intel laptop with this branch (while it worked with 6.1) ?

I don't know. Both of my S3-capable Intel laptops died recently. It is up to someone else now to bisect 6.6 branch.

evadot · 2024-07-04T06:51:51Z

I think that all the linuxkpi patches are in -CURRENT now ?

I placed a bunch of remaining patches to phabricator just now. Except pci_iomap_range one which requires reworking to get proper meteorlake+ support.

What's the status of suspend/resume, iirc @emaste said he had problems on a intel laptop with this branch (while it worked with 6.1) ?

I don't know. Both of my S3-capable Intel laptops died recently. It is up to someone else now to bisect 6.6 branch.

Ok thanks for the info, I'll do test/bisect once all the needed lkpi parts are commited then.

rudrabhoj · 2024-07-07T14:46:09Z

How much longer before we can expect these patches to be merged? What would be the goto way to try this right now?

wulf7 · 2024-07-07T16:03:37Z

All patches are in phabricator now. I expect them to be committed to current in 2 weeks and than MFC-ed to 14-stable 1 week later

wulf7 · 2024-07-21T13:34:32Z

How much longer before we can expect these patches to be merged? What would be the goto way to try this right now?

All patches are merged to CURRENT now. You may test them. Don't forget to add full path to linuxkpi_video.ko module as it conflicts with system one. This may be done e.g. with addition of following lines to rc.conf:
kld_list="/boot/modules/linuxkpi_video.ko /boot/modules/i915kms.ko"
or
kld_list="/boot/modules/linuxkpi_video.ko /boot/modules/amdgpu.ko"

JohnAZoidberg · 2024-07-22T11:27:30Z

I tried it on a AlderLake system and while the driver can load, I get an error when starting Xorg:

intel(0): intel_uxa_set_pixmap_bo: size of buffer object does not match constraints: size=14680064, must be greater than 13860864, but less than 4194304

See attached logfile
Xorg.0.log

My world and kernel is built from freebsd-src on main branch (dirty is just a patch to use a different ethernet driver):

FreeBSD marigold-dvt2 15.0-CURRENT FreeBSD 15.0-CURRENT #3 main-n271308-1cbd613f3343-dirty: Sun Jul 21 20:04:01 UTC 2024     root@marigold-dvt2:/usr/obj/home/zoid/freebsd-src/amd64.amd64/sys/GENERIC-NODEBUG amd64

wulf7 · 2024-07-22T11:32:17Z

intel driver does not work on AlderLake. delete xf86-video-intel and use modesetting

aokblast · 2024-07-24T14:18:26Z

I have tested on Meteor Lake (thought it is unstable in v6.6) and it works fine when entering xorg. But there are problems happen at drmfb as the picture shows. (Not because of my bad photographing skill, what it shows is the real phenomena I saw.

wulf7 · 2024-07-27T12:07:02Z

What is sysctl hw.intel_graphics_stolen_size and sysctl hw.intel_graphics_stolen_base result? Is it non-zero?

aokblast · 2024-07-27T16:37:54Z

All of the value are zeros.

wulf7 · 2024-07-27T21:08:30Z

Probably import of stolen area detection code for MeteorLake will fix the problem. It is on base system side rather then on drm-kmod.

daniloegea · 2024-07-28T11:21:49Z

I tested it on my AMD Ryzen 9 7950X (#305) but unfortunately it's not quite working yet.

Using the Display Port, when I load the driver something apparently works. I don't get any video output after that but the system doesn't hang. I can enter commands and access it via SSH.

When I use the HDMI output it seems to be hanging.

aokblast · 2024-07-28T17:23:35Z

Hmm, I don't find the corresponding quirk in the original Linux kernel source. Maybe it is just unstable. I found intel says Meteor Lake Arc graphic is stable at 6.8.

evadot · 2024-08-02T08:57:43Z

Tested on my RX550, seems to work fine. Suspend-resume is working fine too.

I'll test on some intel devices next week I think.
@wulf7 can you upstream the linuxkpi_video changes to src so we don't have to include this module anymore in drm-kmod ? Thanks

wulf7 · 2024-08-05T00:15:15Z

@wulf7 can you upstream the linuxkpi_video changes to src so we don't have to include this module anymore in drm-kmod

See https://reviews.freebsd.org/D46224

evadot · 2024-08-07T08:25:24Z

@wulf7 can you upstream the linuxkpi_video changes to src so we don't have to include this module anymore in drm-kmod

See https://reviews.freebsd.org/D46224

Thanks.
Since we have (or will have) everything needed in base for linuxkpi_video I'm removed the module from the master branch.
I've also tested on a few intel machine and didn't have any problems so once you've rebased for the linuxkpi_video conflict feel free to merge this into master and if there is any problems we can work from there instead of this PR.

Thanks again.

Fix the following errors reported by checkpatch: ERROR: open brace '{' following struct go on the same line Signed-off-by: Ran Sun <[email protected]> Signed-off-by: Alex Deucher <[email protected]>

Fix the following errors reported by checkpatch: ERROR: open brace '{' following struct go on the same line ERROR: Use C99 flexible arrays Signed-off-by: Ran Sun <[email protected]> Signed-off-by: Alex Deucher <[email protected]>

Fix the following errors reported by checkpatch: ERROR: open brace '{' following struct go on the same line ERROR: space prohibited before open square bracket '[' ERROR: "foo * bar" should be "foo *bar" Signed-off-by: Ran Sun <[email protected]> Signed-off-by: Alex Deucher <[email protected]>

Fix the following errors reported by checkpatch: ERROR: space prohibited before open square bracket '[' ERROR: "foo * bar" should be "foo *bar" Signed-off-by: Ran Sun <[email protected]> Signed-off-by: Alex Deucher <[email protected]>

Fix the following errors reported by checkpatch: ERROR: that open brace { should be on the previous line ERROR: space prohibited before that ',' (ctx:WxW) Signed-off-by: Ran Sun <[email protected]> Signed-off-by: Alex Deucher <[email protected]>

Fix the following errors reported by checkpatch: ERROR: that open brace { should be on the previous line Signed-off-by: Ran Sun <[email protected]> Signed-off-by: Alex Deucher <[email protected]>

If we can't find a free fence register to handle a fault in the GMADR range just return VM_FAULT_NOPAGE without populating the PTE so that userspace will retry the access and trigger another fault. Eventually we should find a free fence and the fault will get properly handled. A further improvement idea might be to reserve a fence (or one per CPU?) for the express purpose of handling faults without having to retry. But that would require some additional work. Looks like this may have gotten broken originally by commit 39965b376601 ("drm/i915: don't trash the gtt when running out of fences") as that changed the errno to -EDEADLK which wasn't handle by the gtt fault code either. But later in commit 2feeb52859fc ("drm/i915/gt: Fix -EDEADLK handling regression") I changed it again to -ENOBUFS as -EDEADLK was now getting used for the ww mutex dance. So this fix only makes sense after that last commit. Cc: [email protected] Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9479 Fixes: 2feeb52859fc ("drm/i915/gt: Fix -EDEADLK handling regression") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Andi Shyti <[email protected]> (cherry picked from commit 7f403caabe811b88ab0de3811ff3f4782c415761) Signed-off-by: Rodrigo Vivi <[email protected]>

Looks like RADV is actually hitting this. Signed-off-by: Christian König <[email protected]> Fixes: ca6c1e210aa7 ("drm/amdgpu: use the new drm_exec object for CS v3") Acked-by: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

As drm_dp_get_mst_branch_device_by_guid() is called from drm_dp_get_mst_branch_device_by_guid(), mstb parameter has to be checked, otherwise NULL dereference may occur in the call to the memcpy() and cause following: [12579.365869] BUG: kernel NULL pointer dereference, address: 0000000000000049 [12579.365878] #PF: supervisor read access in kernel mode [12579.365880] #PF: error_code(0x0000) - not-present page [12579.365882] PGD 0 P4D 0 [12579.365887] Oops: 0000 [freebsd#1] PREEMPT SMP NOPTI ... [12579.365895] Workqueue: events_long drm_dp_mst_up_req_work [12579.365899] RIP: 0010:memcmp+0xb/0x29 [12579.365921] Call Trace: [12579.365927] get_mst_branch_device_by_guid_helper+0x22/0x64 [12579.365930] drm_dp_mst_up_req_work+0x137/0x416 [12579.365933] process_one_work+0x1d0/0x419 [12579.365935] worker_thread+0x11a/0x289 [12579.365938] kthread+0x13e/0x14f [12579.365941] ? process_one_work+0x419/0x419 [12579.365943] ? kthread_blkcg+0x31/0x31 [12579.365946] ret_from_fork+0x1f/0x30 As get_mst_branch_device_by_guid_helper() is recursive, moving condition to the first line allow to remove a similar one for step over of NULL elements inside a loop. Fixes: 5e93b8208d3c ("drm/dp/mst: move GUID storage from mgr, port to only mst branch") Cc: <[email protected]> # 4.14+ Signed-off-by: Lukasz Majczak <[email protected]> Reviewed-by: Radoslaw Biernacki <[email protected]> Signed-off-by: Manasi Navare <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

abo->tbo.resource may be NULL in amdgpu_vm_bo_update. Fixes: 180253782038 ("drm/ttm: stop allocating dummy resources during BO creation") Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>

In amdgpu_dma_buf_move_notify reserve fences for the page table updates in amdgpu_vm_clear_freed and amdgpu_vm_handle_moved. This fixes a BUG_ON in dma_resv_add_fence when using SDMA for page table updates. Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>

Remove a redundant call to amdgpu_ctx_priority_is_valid() from amdgpu_ctx_priority_permit(), which is called from amdgpu_ctx_init() which is called from amdgpu_ctx_alloc() which is called from amdgpu_ctx_ioctl(), where we've called amdgpu_ctx_priority_is_valid() already first thing in the function. Cc: Alex Deucher <[email protected]> Cc: Christian König <[email protected]> Signed-off-by: Luben Tuikov <[email protected]> Acked-by: Christian König <[email protected]> Link: https://lore.kernel.org/r/[email protected]

When supporting OA for TGL, it was seen that the context valid bit in the report ID was not defined, however revisiting the spec seems to have this bit defined. The bit is used to determine if a context is valid on a context switch and is essential to determine active and idle periods for a context. Re-enable the context valid bit for gen12 platforms. BSpec: 52196 (description of report_id) v2: Include BSpec reference (Ashutosh) Fixes: 00a7f0d7155c ("drm/i915/tgl: Add perf support on TGL") Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 7eeaedf79989a8f131939782832e21e9218ed2a0) Signed-off-by: Rodrigo Vivi <[email protected]>

The steering control and semaphore registers are inside an "always on" power domain with respect to RC6. However there are some issues if higher-level platform sleep states are entering/exiting at the same time these registers are accessed. Grabbing GT forcewake and holding it over the entire lock/steer/unlock cycle ensures that those sleep states have been fully exited before we access these registers. This is expected to become a formally documented/numbered workaround soon. Note that this patch alone isn't expected to have an immediately noticeable impact on MCR (mis)behavior; an upcoming pcode firmware update will also be necessary to provide the other half of this workaround. v2: - Move the forcewake inside the Xe_LPG-specific IP version check. This should only be necessary on platforms that have a steering semaphore. Fixes: 3100240bf846 ("drm/i915/mtl: Add hardware-level lock for steering") Cc: Radhakrishna Sripada <[email protected]> Cc: Jonathan Cavitt <[email protected]> Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Radhakrishna Sripada <[email protected]> Reviewed-by: Jonathan Cavitt <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 8fa1c7cd1fe9cdfc426a603e1f1eecd3f463c487) Signed-off-by: Rodrigo Vivi <[email protected]>

When the driver unbinds, pmu is unregistered and i915->uabi_engines is set to RB_ROOT. Due to this, when i915 PMU tries to stop the engine events, it issues a warn_on because engine lookup fails. All perf hooks are taking care of this using a pmu->closed flag that is set when PMU unregisters. The stop event seems to have been left out. Check for pmu->closed in pmu_event_stop as well. Based on discussion here - https://patchwork.freedesktop.org/patch/492079/?series=105790&rev=2 v2: s/is/if/ in commit title v3: Add fixes tag and cc stable Cc: <[email protected]> # v5.11+ Fixes: b00bccb3f0bb ("drm/i915/pmu: Handle PCI unbind") Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 31f6a06f0c543b43a38fab10f39e5fc45ad62aa2) Signed-off-by: Rodrigo Vivi <[email protected]>

Originally we were quirking ASPM disabled specifically for VI when used with Alder Lake, but it appears to have problems with Rocket Lake as well. Like we've done in the case of dpm for newer platforms, disable ASPM for all Intel systems. Cc: [email protected] # 5.15+ Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default") Reported-and-tested-by: Paolo Gentili <[email protected]> Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2036742 Signed-off-by: Mario Limonciello <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>

If *any* object of a certain WW mutex class is locked, lockdep will consider *all* mutexes of that class as locked. Also the lock allocation tracking code will apparently register only the address of the first mutex of a given class locked in a sequence. This has the odd consequence that if that first mutex is unlocked while other mutexes of the same class remain locked and then its memory then freed, the lock alloc tracking code will incorrectly assume that memory is freed with a held lock in there. For now, work around that for drm_exec by releasing the first grabbed object lock last. v2: - Fix a typo (Danilo Krummrich) - Reword the commit message a bit. - Add a Fixes: tag Related lock alloc tracking warning: [ 322.660067] ========================= [ 322.660070] WARNING: held lock freed! [ 322.660074] 6.5.0-rc7+ freebsd#155 Tainted: G U N [ 322.660078] ------------------------- [ 322.660081] kunit_try_catch/4981 is freeing memory ffff888112adc000-ffff888112adc3ff, with a lock still held there! [ 322.660089] ffff888112adc1a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_exec_lock_obj+0x11a/0x600 [drm_exec] [ 322.660104] 2 locks held by kunit_try_catch/4981: [ 322.660108] #0: ffffc9000343fe18 (reservation_ww_class_acquire){+.+.}-{0:0}, at: test_early_put+0x22f/0x490 [drm_exec_test] [ 322.660123] freebsd#1: ffff888112adc1a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_exec_lock_obj+0x11a/0x600 [drm_exec] [ 322.660135] stack backtrace: [ 322.660139] CPU: 7 PID: 4981 Comm: kunit_try_catch Tainted: G U N 6.5.0-rc7+ freebsd#155 [ 322.660146] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021 [ 322.660152] Call Trace: [ 322.660155] <TASK> [ 322.660158] dump_stack_lvl+0x57/0x90 [ 322.660164] debug_check_no_locks_freed+0x20b/0x2b0 [ 322.660172] slab_free_freelist_hook+0xa1/0x160 [ 322.660179] ? drm_exec_unlock_all+0x168/0x2a0 [drm_exec] [ 322.660186] __kmem_cache_free+0xb2/0x290 [ 322.660192] drm_exec_unlock_all+0x168/0x2a0 [drm_exec] [ 322.660200] drm_exec_fini+0xf/0x1c0 [drm_exec] [ 322.660206] test_early_put+0x289/0x490 [drm_exec_test] [ 322.660215] ? __pfx_test_early_put+0x10/0x10 [drm_exec_test] [ 322.660222] ? __kasan_check_byte+0xf/0x40 [ 322.660227] ? __ksize+0x63/0x140 [ 322.660233] ? drmm_add_final_kfree+0x3e/0xa0 [drm] [ 322.660289] ? _raw_spin_unlock_irqrestore+0x30/0x60 [ 322.660294] ? lockdep_hardirqs_on+0x7d/0x100 [ 322.660301] ? __pfx_kunit_try_run_case+0x10/0x10 [kunit] [ 322.660310] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] [ 322.660319] kunit_generic_run_threadfn_adapter+0x4a/0x90 [kunit] [ 322.660328] kthread+0x2e7/0x3c0 [ 322.660334] ? __pfx_kthread+0x10/0x10 [ 322.660339] ret_from_fork+0x2d/0x70 [ 322.660345] ? __pfx_kthread+0x10/0x10 [ 322.660349] ret_from_fork_asm+0x1b/0x30 [ 322.660358] </TASK> [ 322.660818] ok 8 test_early_put Cc: Christian König <[email protected]> Cc: Boris Brezillon <[email protected]> Cc: Danilo Krummrich <[email protected]> Cc: [email protected] Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7") Signed-off-by: Thomas Hellström <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Reviewed-by: Danilo Krummrich <[email protected]> Reviewed-by: Christian König <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

They are stubbed in LinuxKPI now. Sponsored by: Serenity Cyber Security, LLC

The function has been removed since Linux kernel v5.4. Sponsored by: Serenity Cyber Security, LLC

With addition of following files: - drivers/gpu/drm/amd/display/dc/dce/dce_clk_mgr.c - drivers/gpu/drm/ttm/tests/* - include/drm/drm_gem_dma_helper.h - include/drm/drm_gpuva_mgr.h - include/drm/drm_kunit_helpers.h - include/uapi/drm/ivpu_accel.h Sponsored by: Serenity Cyber Security, LLC

Sponsored by: Serenity Cyber Security, LLC

It is unneeded as sysfs link support is stubbed in LKPI now Sponsored by: Serenity Cyber Security, LLC

It is unneeded as sysfs link support routines are stubbed in LKPI now Sponsored by: Serenity Cyber Security, LLC

Sponsored by: Serenity CyberSecurity, LLC Fixes: "drm/amdgpu: register a dirty framebuffer callback for fbcon"

chrislongros · 2024-08-10T19:54:20Z

I compiled the drm-61-kmod port under FreeBSD CURRENT but I did not set kld_list="/boot/modules/linuxkpi_video.ko /boot/modules/amdgpu.ko" ... I used # sysrc kld_list+=amdgpu instead and I got another kernel panic :(

chrislongros · 2024-08-10T19:55:22Z

Is there a way to fix it from this point or should I reinstall FreeBSD? What do you think is the problem?

wulf7 · 2024-08-10T20:39:17Z

I bet you forget to install firmwares

chrislongros · 2024-08-10T20:44:28Z

Yeah 😅 I thought the port provided them

It is a part of LKPI in the base system now. It may be reenabled with adding DEVELOPER parameter to make. This effectively reapplies 199e4b9 "linuxkpi_video: Remove module" Sponsored by: Serenity CyberSecurity, LLC

wulf7 · 2024-08-11T11:00:03Z

feel free to merge this into master and if there is any problems we can work from there instead of this PR.

done

wulf7 marked this pull request as draft January 29, 2024 23:23

emaste mentioned this pull request Feb 1, 2024

kernel panic from intel_gt_sysfs_get_drvdata after sysctl -a (INVARIANTS kernel, master branch 6.1) #280

Open

Alexander88207 mentioned this pull request May 5, 2024

drm 6.1,6.6: FreeSync/VRR doesnt work correctly. #298

Open

wulf7 force-pushed the update-to-v6.6 branch from 3946801 to 74cd119 Compare July 7, 2024 17:08

wulf7 force-pushed the update-to-v6.6 branch from 74cd119 to 56b26f5 Compare July 21, 2024 13:22

wulf7 changed the title ~~WIP: Update to Linux v6.6 drivers~~ Update to Linux v6.6 drivers Jul 21, 2024

wulf7 marked this pull request as ready for review July 21, 2024 13:26

Ran Sun added 6 commits August 9, 2024 22:15

drm/amd/pm: Clean up errors in hardwaremanager.h

355335d

Fix the following errors reported by checkpatch: ERROR: open brace '{' following struct go on the same line Signed-off-by: Ran Sun <[email protected]> Signed-off-by: Alex Deucher <[email protected]>

drm/amd/pm: Clean up errors in hwmgr.h

384c7f2

Fix the following errors reported by checkpatch: ERROR: open brace '{' following struct go on the same line ERROR: Use C99 flexible arrays Signed-off-by: Ran Sun <[email protected]> Signed-off-by: Alex Deucher <[email protected]>

drm/amd/pm: Clean up errors in smu75.h

2789984

Fix the following errors reported by checkpatch: ERROR: space prohibited before open square bracket '[' ERROR: "foo * bar" should be "foo *bar" Signed-off-by: Ran Sun <[email protected]> Signed-off-by: Alex Deucher <[email protected]>

drm/amd/pm: Clean up errors in r600_dpm.h

7f675d8

Fix the following errors reported by checkpatch: ERROR: that open brace { should be on the previous line Signed-off-by: Ran Sun <[email protected]> Signed-off-by: Alex Deucher <[email protected]>

vsyrjala and others added 21 commits August 9, 2024 22:15

i915/display: un-#ifdef cpu_latency_qos calls

fef6923

They are stubbed in LinuxKPI now. Sponsored by: Serenity Cyber Security, LLC

i915/gt/uc: Remove intel_guc_log_relay_enabled stub

4d0f17a

The function has been removed since Linux kernel v5.4. Sponsored by: Serenity Cyber Security, LLC

scripts/diffignore: Add GPL-ed include/drm/drm_gpuva_mgr.h file

bef743a

Sponsored by: Serenity Cyber Security, LLC

un-#ifdef sysfs link support in drivers/gpu/drm/drm_drv.c

4f10db0

It is unneeded as sysfs link support is stubbed in LKPI now Sponsored by: Serenity Cyber Security, LLC

amd/amdgpu: un-#ifdef sysfs link support in amd/amdgpu/amdgpu_xgmi.c

de5e649

It is unneeded as sysfs link support routines are stubbed in LKPI now Sponsored by: Serenity Cyber Security, LLC

i915/display: un-#ifdef sysfs link support in i915/display/intel_hdmi.c

9aa880a

It is unneeded as sysfs link support routines are stubbed in LKPI now Sponsored by: Serenity Cyber Security, LLC

i915/display: un-#ifdef sysfs link support in i915/display/intel_sdvo.c

294719d

It is unneeded as sysfs link support routines are stubbed in LKPI now Sponsored by: Serenity Cyber Security, LLC

Replace linux_pci_(un)register_drm_driver calls with driver name change

b5b41f0

amdgpu: Fix kernel hangup on crash dump creation

a76610e

Sponsored by: Serenity CyberSecurity, LLC Fixes: "drm/amdgpu: register a dirty framebuffer callback for fbcon"

Disable building of linuxkpi_video.ko by default

ad81525

It is a part of LKPI in the base system now. It may be reenabled with adding DEVELOPER parameter to make. This effectively reapplies 199e4b9 "linuxkpi_video: Remove module" Sponsored by: Serenity CyberSecurity, LLC

wulf7 force-pushed the update-to-v6.6 branch from febb599 to ad81525 Compare August 11, 2024 10:38

wulf7 merged commit ad81525 into freebsd:master Aug 11, 2024
1 check failed

kenrap mentioned this pull request Aug 31, 2024

Intel Arc A770: Kernel panic on kldload i915kms.ko #315

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update to Linux v6.6 drivers #283

Update to Linux v6.6 drivers #283

wulf7 commented Jan 29, 2024 •

edited

Loading

evadot commented Jun 27, 2024

wulf7 commented Jul 2, 2024

evadot commented Jul 4, 2024

rudrabhoj commented Jul 7, 2024

wulf7 commented Jul 7, 2024

wulf7 commented Jul 21, 2024

JohnAZoidberg commented Jul 22, 2024 •

edited

Loading

wulf7 commented Jul 22, 2024 •

edited

Loading

aokblast commented Jul 24, 2024 •

edited

Loading

wulf7 commented Jul 27, 2024

aokblast commented Jul 27, 2024

wulf7 commented Jul 27, 2024

daniloegea commented Jul 28, 2024

aokblast commented Jul 28, 2024

evadot commented Aug 2, 2024

wulf7 commented Aug 5, 2024

evadot commented Aug 7, 2024

chrislongros commented Aug 10, 2024

chrislongros commented Aug 10, 2024

wulf7 commented Aug 10, 2024

chrislongros commented Aug 10, 2024 •

edited

Loading

wulf7 commented Aug 11, 2024

Update to Linux v6.6 drivers #283

Update to Linux v6.6 drivers #283

Conversation

wulf7 commented Jan 29, 2024 • edited Loading

evadot commented Jun 27, 2024

wulf7 commented Jul 2, 2024

evadot commented Jul 4, 2024

rudrabhoj commented Jul 7, 2024

wulf7 commented Jul 7, 2024

wulf7 commented Jul 21, 2024

JohnAZoidberg commented Jul 22, 2024 • edited Loading

wulf7 commented Jul 22, 2024 • edited Loading

aokblast commented Jul 24, 2024 • edited Loading

wulf7 commented Jul 27, 2024

aokblast commented Jul 27, 2024

wulf7 commented Jul 27, 2024

daniloegea commented Jul 28, 2024

aokblast commented Jul 28, 2024

evadot commented Aug 2, 2024

wulf7 commented Aug 5, 2024

evadot commented Aug 7, 2024

chrislongros commented Aug 10, 2024

chrislongros commented Aug 10, 2024

wulf7 commented Aug 10, 2024

chrislongros commented Aug 10, 2024 • edited Loading

wulf7 commented Aug 11, 2024

wulf7 commented Jan 29, 2024 •

edited

Loading

JohnAZoidberg commented Jul 22, 2024 •

edited

Loading

wulf7 commented Jul 22, 2024 •

edited

Loading

aokblast commented Jul 24, 2024 •

edited

Loading

chrislongros commented Aug 10, 2024 •

edited

Loading