Re: Alder lake supported? (graphics)
Chris writes: > I upgraded to an alder lake based machine and installed 14. > But I can't seem to get the intel graphics loaded (drm-515-kmod). > It simply freezes at load. > Are Alder lake graphics supported? Try drm-61-kmod instead (with gpu-firmware-intel-kmod-alderlake >= 20230625). Reported success in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270888#c8 > releng/14.0-n265380-f9716eee8ab4 > 12th Gen Intel(R) Core(TM) i3-1215U > vgapci0@pci0:0:2:0: class=0x03 rev=0x0c hdr=0x00 vendor=0x8086 > device=0x46b3 subvendor=0x17aa subdevice=0x3b3a > vendor = 'Intel Corporation' > device = 'Alder Lake-UP3 GT1 [UHD Graphics]' > class = display > subclass = VGA 0x46b3 aka ADL-P is unstable with Linux < 5.17 or in drm-515-kmod. https://github.com/torvalds/linux/commit/dfb924e33927 https://github.com/freebsd/drm-kmod/commit/3403defd86e5 include/drm/i915_pciids.h contains a list of supported Intel GPUs. drivers/gpu/drm/i915/i915_pci.c with .require_force_probe contain a list of unstable GPU generations. Previously, Linux < 5.5 used alpha_support and Linux < 4.9 used .preliminary_hw_support. drm-kmod doesn't support hw.i915kms.force_probe (via loader.conf or kenv) tunable yet thus cannot override .require_force_probe for specific GPUs. Instead it sets DRM_I915_FORCE_PROBE="*" to enable all unstable support. https://github.com/freebsd/drm-kmod/commit/054cb0598cab
Re: Alder lake supported? (graphics)
In message , Chris writes: >I upgraded to an alder lake based machine and installed 14. >But I can't seem to get the intel graphics loaded (drm-515-kmod). >It simply freezes at load. Shot in the dark: # pkg delete drm-515-kmod && pkg install drm-510-kmod && kldload i915kms John groenv...@acm.org
Alder lake supported? (graphics)
I upgraded to an alder lake based machine and installed 14. But I can't seem to get the intel graphics loaded (drm-515-kmod). It simply freezes at load. Are Alder lake graphics supported? releng/14.0-n265380-f9716eee8ab4 12th Gen Intel(R) Core(TM) i3-1215U vgapci0@pci0:0:2:0: class=0x03 rev=0x0c hdr=0x00 vendor=0x8086 device=0x46b3 subvendor=0x17aa subdevice=0x3b3a vendor = 'Intel Corporation' device = 'Alder Lake-UP3 GT1 [UHD Graphics]' class = display subclass = VGA Thanks for any clues here. :-) --Chris
Re: noatime on ufs2
Chris wrote in <9155214edb61b1bc3bad3bc96f96e...@bsdforge.com>: ... |I haven't seen anything in this thread that wouldn't be better placed in |tuning(7) |or tunefs(8). | |* Silicon disks fail without warning | tapes did as well. Unless you're working with punch cards please \ | implement |an | effective backup strategy -- snapshot(8) |* writing to my disk takes a long time | see tuning(7) or tunefs(8) |* atime doesn't work like "realtime" does on Linux | use Linux instead or add the ability to also use realtime 'Seems to me from a "git grep" that ZFS supports relatime. The number of atime matches for ufs is not that horrifying either. Sure the daily disc crawler touches anything, as was said, so relatime does not help once. For that the crawlers (locate, whatis, whatever) would need to use O_NOATIME, but FreeBSD says /* XXX LINUX_O_NOATIME: unable to be easily implemented. */, so that sucks. Maybe then noatime is the better way out. Having said that, i have never tried it, whether nullfs overmount for the crawlers would get over that. Would be a good thing i'd say, for jailed servers or what. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Request for Testing: TCP RACK
W dniu 17.11.2023 o 00:13, tue...@fh-muenster.de pisze: On Nov 16, 2023, at 17:50, Marek Zarychta wrote: W dniu 16.11.2023 o 10:13, tue...@freebsd.org pisze: Dear all, recently the main branch was changed to build the TCP RACK stack which is a loadable kernel module, by default: https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc That's really good news and long-awaited change. Thank you. As discussed on the bi-weekly transport call, it would be great if people could test the RACK stack for their workload. Please report any problems to the net@ mailing list or open an issue in the bug tracker and drop me a note via email. This includes regressions in CPU usage, regressions in performance or any other unexpected change you observe. You can load the kernel module using kldload tcp_rack You can make the RACK stack the default stack using sysctl net.inet.tcp.functions_default=rack Based on the feedback we get, the default stack might be switched to the RACK stack. Yes, please do it, at least for CURRENT. Last problem I have spotted with RACK was fixed in June: it was missing support TCP-MD5: https://cgit.freebsd.org/src/commit/?id=02b885b09d1e90574162a1442b9ede06cef2b13a We switched to RACK since upgrading to early stable/13 and genuinely appreciate this gift from Netflix. The performance improvement is invaluable, both in a lossy LAN and on a long-haul overseas TCP connection. Please let me know if you have any questions. Are any MFCs planned, especially to stable/14 ? Now, when stable/14 is almost in sync with main aka CURRENT it's an optimal time for such a MFC. When the change hits stable/14, it would be possible to test it extensively and have it fully functional in 14.1-RELEASE. Let me bring that up on the next Transport call. Will report back. Best regards Michael Thank you ! From now on stable/14 and in the future on 14.1-RELEASE one will be able to load tcp_rack and tcp_bbr out of the box running GENERIC kernel.[1] 1. https://cgit.freebsd.org/src/commit/?id=123fd2a -- Marek Zarychta
Re: suspend to idle support
16.01.24 20:29, Warner Losh: On Mon, Jan 15, 2024 at 10:24 AM Oleksandr Kryvulia wrote: Hello, What is a status of support suspend to idle? I found only two related reviews D17675 and D17676 and no more any information. It is a very desirable thing on modern laptops, where s3 is not supported like my X1 Carbon gen11[1]. [1] https://wiki.freebsd.org/Laptops/Thinkpad_X1_Carbon It works for me on my Lenovo Yoga that's a couple of years old, modulo the build-in wifi card. On my X1: hw.acpi.supported_sleep_state: S4 S5 So no S3 state and no suspend-resume support. The erlier versions have a settings in BIOS which allow to enable S3 support, but not mine. Can you share your experience with how you set it up?
Re: suspend to idle support
On Mon, Jan 15, 2024 at 10:24 AM Oleksandr Kryvulia wrote: > Hello, > What is a status of support suspend to idle? I found only two related > reviews D17675 and D17676 and no more any information. It is a very > desirable thing on modern laptops, where s3 is not supported like my X1 > Carbon gen11[1]. > > [1] https://wiki.freebsd.org/Laptops/Thinkpad_X1_Carbon > It works for me on my Lenovo Yoga that's a couple of years old, modulo the build-in wifi card. Warner
Re: noatime on ufs2
On 2024-01-09 00:47, Olivier Certner wrote: Why not make noatime the default across the whole system? Outside of mbox why is recording access time actually useful? Exactly. I've never found any compelling reason in most uses to enable "atime", except perhaps local mail but as addressed in other answers it is a relic of the past mostly irrelevant today. And its drawbacks are well known and can be serious. The auditing use is not what I consider "normal" in the sense I suspect it concerns a small minority of users (maybe even tiny). Plus, serious auditing requires keeping a log (generally immutable) of accesses, i.e., more than a single time and, as pointed out in another answer, at least the ID of the user performing the access. Updating the access time field on files/directories doesn't address both. What "relatime" only gives you is a guarantee that you know that some file has been accessed at some point after its last modification (or creation), and that the access time is correct if precision is only a day. It also generally lowers I/O obviously, but not in some scenarios (file creation and subsequent read). So, to me, at this point, it still sounds more than a gimmick than something really useful. If someone has a precise use case for it and motivation, than of course please go ahead. In the short term, I'd vote for turning "atime" off by default. Thanks and regards. Honestly! Why do we have to upend decades of usage and understanding? Just because it's old doesn't mean it's wrong. Several weeks of replies confirm my initial belief -- atime as it is currently implemented, is as it should be. Administrators and users have spent years to decades finessing their systems and policies based on the way the OS works. In fact administrators and users *pick* their OS based on the way it works. In the case of atime; decades of scripting/policy and utilities have been created based upon the it's expected behavior on any given OS. I haven't seen anything in this thread that wouldn't be better placed in tuning(7) or tunefs(8). * Silicon disks fail without warning tapes did as well. Unless you're working with punch cards please implement an effective backup strategy -- snapshot(8) * writing to my disk takes a long time see tuning(7) or tunefs(8) * atime doesn't work like "realtime" does on Linux use Linux instead or add the ability to also use realtime Security and forensics are good reasons to keep atime unchanged. Any discussion regarding changes to it's current behavior seems folly or bikeshedding. Apologies for the "attitude". --Chris
