User Details
- User Since
- May 14 2014, 7:33 AM (575 w, 17 h)
Sun, May 18
Yes, when unloading a kernel module the drivers defined with DRIVER_MODULE appear to be deleted in reverse order.
Sat, May 17
Drain callout and taskqueue before shutting down child devices
Mon, May 12
Mar 24 2025
Mar 23 2025
Mar 17 2025
Feb 11 2025
Feb 10 2025
Feb 8 2025
Jan 17 2025
Jan 7 2025
Jan 2 2025
Jan 1 2025
Dec 31 2024
Dec 29 2024
Dec 28 2024
Dec 26 2024
Dec 23 2024
Dec 3 2024
Nov 30 2024
Nov 26 2024
Oct 11 2024
Oct 2 2024
Sep 27 2024
Sep 24 2024
Sep 23 2024
Sep 15 2024
Sep 1 2024
bmake calls uname(3) to define MACHINE and that returns the value of environment variable UNAME_m which is defined by poudriere so MACHINE should be correct. MACHINE_ARCH cannot be obtained through uname(3) so bmake has to call sysctl which will indeed return the native architecture. I think it's best to add MACHINE_ARCH=${ARCH} to WRK_ENV in Mk/bsd.port.mk so it applies to all ports not just kmod ports.
Aug 31 2024
Aug 24 2024
Aug 17 2024
Jul 28 2024
Jul 20 2024
Jul 13 2024
Jul 8 2024
Jun 22 2024
Jun 21 2024
Jun 14 2024
Jun 5 2024
May 13 2024
May 12 2024
May 11 2024
May 8 2024
I spent yesterday and today on this but it's taking too much time to familiarise myself with the code so I won't be able to fix this in a timely manner. It's also too risky to make changes to drm-*-kmod this close to 14.1. So I've created D45125 which should be safe to MFC.
May 3 2024
Maybe it would be better to turn arch_io_reserve_memtype_wc into a no-op returning 0 and leave the drm-*-kmod ports unchanged. That would be safer this close to 14.1 release. Before 1e99b2ee9095 the function interpreted a physical address as a virtual address so it must have always failed and after that commit the BSDFIXME comment in the link I posted before suggests it still doesn't work. So whatever this function is supposed to do has not been necessary on FreeBSD. The only benefit of implementing it as a wrapper around vm_phys_fictitious_reg_range is that it makes the FreeBSD specific code in drm-*-kmod smaller, but that's not important. Agreed?
May 2 2024
The patch for graphics/drm-*-kmod ports is in D45059.
Example use of arch_io_reserve_memtype_wc:
https://github.com/freebsd/drm-kmod/blob/1f0859f54b6f4bcce3862f30c9c1b5cfd08710db/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c#L1048
Note that arch_io_reserve_memtype_wc is only called conditionally here so removing vm_phys_fictitious_reg_range calls like the drm-*-kmod patch does may not be correct. The i915 driver doesn't call arch_io_reserve_memtype_wc at all. It calls io_mapping_init_wc instead, which calls ioremap_wc, which calls pmap_mapdev_attr, so I think it doesn't need to call vm_phys_fictitious_reg_range but I cannot test that.
Example use:
https://github.com/freebsd/drm-kmod/blob/1f0859f54b6f4bcce3862f30c9c1b5cfd08710db/drivers/gpu/drm/radeon/radeon_gart.c#L83
set_memory_uc called on ptr returned by linuxkpi dma_alloc_coherent, which returns a virtual address.