Create accountLogin

Recent searches

No recent searches

Search options

Not available on lingo.lol.
lingo.lol is one of the many independent Mastodon servers you can use to participate in the fediverse.
A place for linguists, philologists, and other lovers of languages.

Administered by:

Server stats:

64
active users

lingo.lol: AboutProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.7

#FreeBSD

36 posts33 participants2 posts today
Public
chesheer

The old FreeBSD master Vi was praised by many sysadmins for his perfect understanding of FreeBSD and pure life.
Once some youngster decided to test master Vi's knowledge and asked him: "Tell me, oh Master, how did you configure your servers?"
Master Vi answered: "I don't really know".
Disappointed youngster returned to his own master and told him: "Master Vi is just a pretentious old man, he doesn't know anything. I know every configuration file in all of my Linux installations".
His Master gave him a slap upside the head and said: "Master Vi configured his servers when these mountains were still young and this river was but a small spring. He never needed this knowledge again, because his servers have worked flawlessly ever since. This is why his understanding is perfect".
#FreeBSD

Continued thread
Public
Toby Kurien

Ok, so check this out. I raved about how magical #FreeBSD #linuxulator is, but it gets even better! In my Ubuntu linux jail, I downloaded the source for the #mobian kernel, installed cross-compiling tools, compiled the kernel and modules, copied to an sdcard, and booted up the kernel on my #pinephonepro 🤯 So, on my amd64 FreeBSD, I used a translation layer to load up Ubuntu Linux, used it to cross-compile a Linux kernel for arm64, and booted that up on a device! How unbelievable is that?!?

Public
♡ Eva Winterschön ♡

💾 Quick HomeLab Update 💾

As a follow up to this morning's iGPU 512M GART debugging (re: drm-61-kmod memory leak on amdgpu.ko), here are some pics. Reluctantly, the "ok fine" method for testing the memory leak allocation aspects involves using a non-integrated GPU which requires the same driver, for which this low-TDP single-slot AMD W7500 was acquired. Sometime tomorrow it will be installed in my workstation, which is the third chassis from the bottom (4U) situated above the two 5U chassis (HCI private cloud for GPU compute VMs).

More to follow...

#gpu #amd #ai #homelab #freebsd #linux #

Public
Lars Engels

Today I saw that since Bastille's last release at the end of January there have been 625(!) commits to the repo. Many bug fixes, new features, subcommands, doc updates (💜), ...
Big props to Victor for working tiredlessly on the project. github.com/BastilleBSD/bastill

Also, there have been some new videos on Bastille's Youtube channel: youtube.com/@BastilleBSD demonstration upcoming features in Bastille 0.14.

Bastille is an open-source system for automating deployment and management of containerized applications on FreeBSD. - BastilleBSD/bastille
GitHubGitHub - BastilleBSD/bastille: Bastille is an open-source system for automating deployment and management of containerized applications on FreeBSD.Bastille is an open-source system for automating deployment and management of containerized applications on FreeBSD. - BastilleBSD/bastille
#FreeBSD#Jails#Bastille
Continued thread
Public
♡ Eva Winterschön ♡

Panic most recently used by lkpikmalloc ...

Well, that was fast... didn't even get a mouse cursor of a full MATE Desktop menu system load. Was yet to connect kgdb to COM1 (need to swap from minicom to do so)... makes me want a PCIe RS232 card (for "comconsole_pcidev") so that I have a few more COMs to play with on redirects. Gotta love these iGPU tash-bins eh? "It's better than not having a GPU right?" ... not really.''

Closed bug report from the drm-515-kmod, discussing amdgpu memory leak. so, maybe a new one in drm-61-kmod, would not be surprised.
- github.com/freebsd/drm-kmod/is

Short term revision of approach:
----

1. Today via post arrives, an AMD Radeon Pro W7500 (single slot 8GB, Navi-whatever gen)
2. I'll block off the iGPU during loader.conf sequence, using a "pptdev" blackhole (not for VM pt, but maybe an experiment for a 14.1 VM with the known-good amdgpu version).
3. Known as: throw money at the problem?

Some hardware notes:
----

1. This is not a Nvidia GPU situation; there are several generations of cards in the room which have been cycled through the workstation during "hardware isolation" and "process of elimination" sequences. I know those are stable, and which gen cards require which nvidia driver versions for stability purposes.

2. This is not a FreeBSD kernel issue, nor a Xorg "Plain Jane FrameBuffer" situation. The kernel (14.0, 14.1, 14.2) is stable and fine, and the basic vt driver for non-4K display-port functionality works fine. I can work all day in a series of tmux windows with some fifty or so panes, but that's not quite the optimal experience.

3. The AMD iGPU (Raphael) maxes out default to 512MB GART VRAM, and it can handle 240Hz @ 4K all day with no issues as long as that 512M doesn't get used up... that is until the latest amdgpu kmod drm, which crashes whenever it feels like it.

Michael... yes yes, I do have a lot of hardware, but this issue has surpassed the Sunk Cost Fallacy and has become a consumate knowledge-requirement process. I must know where this is failing so horrendously, otherwise the operating rule of "if it doesn't fulfill its hardware destiny, it will get the hammer and flames"... and the hardware is too nice for that - plus I could involve Supermicro support since it's still in warranty, but a replacement motherboard or CPU for the iGPU isn't going to solve a kernel module issue.

In the interim, laptop life and tablet meetings are getting me by, mostly decently.

Debug items of interest:
----
intsmb0: <AMD FCH SMBus Controller> at device 20.0 on pci0
intsmb0: Could not allocate I/O space
device_attach: intsmb0 attach returned 6

drmn0: Fetched VBIOS from VFCT
amdgpu: ATOM BIOS: 102-RAPHAEL-008
drmn0: Trusted Memory Zone (TMZ) feature not supported
drmn0: PCIE atomic ops is not supported
drmn0: VRAM: 512M 0x000000F400000000 - 0x000000F41FFFFFFF (512M used)
[drm ERROR :amdgpu_bo_init] Unable to set WC memtype for the aperture base

Loader items of usage:
----
# Multi-Console Output
# boot output primary: TTY, standard monitor via UEFI
# boot output secondary: COM1 RS232 Redirect (physical)
# boot output tertiary: COM2 RS232 Redirect (BMC SoL)
ipmi_load="YES"
boot_mute="NO"
boot_verbose="YES"
verbose_loading="YES"
boot_multicons="YES"
boot_serial="YES"
console="efi,comconsole,comconsole"
comconsole_port1="0x3F8"
comconsole_speed1="115200"
comconsole_port2="0x2F8"
comconsole_speed2="115200"
hw.uart.console="io:0x3f8,br:115200 io:0x2f8,br:115200"

#amd#gpu#drm616kmod
Public
♡ Eva Winterschön ♡

💾 4am AMD Xorg/Kernel Debugging 💾

Ongoing fun ongoes, so much so. This iteration receives triple output: tty video (Display Port), COM1 redirect via DB9 to laptop running minicom, COM2 to the usual BMC SoL terminal watched from ipmitool on adjacent laptop.

Coming up, rebooting into GENERIC-DEBUG kernel rebuilt with remote GDM (kgdb) access via the COM1 link to laptop.

monitor connected to desktop, showing Xorg session log during tty crash handler exit
monitor connected to desktop, with separate laptop connected to desktop via COM1 and COM2 serial links, as described in the post. color and contrast boosted for low light readability.
#freebsd#epyc#desktop
Public
Felix Palmen :freebsd: :c64:

Today, I implemented the #async / #await pattern (as known from #csharp and meanwhile quite some other languages) ...

... in good old #C! 😎

Well, at least sort of.

* It requires some standard library support, namely #POSIX user context switching with #getcontext and friends, which was deprecated in POSIX-1.2008. But it's still available on many systems, including #FreeBSD, #NetBSD, #Linux (with #glibc). It's NOT available e.g. on #OpenBSD, or Linux with some alternative libc.

* I can't do anything about the basic language syntax, so some boilerplate comes with using it.

* It has some overhead (room for extra stacks, even extra syscalls as getcontext unfortunately also always saves/restores the signal mask)

But then ... async/await in C! 🥳

Here are the docs:
zirias.github.io/poser/api/lat

zirias.github.ioposer: PSC_AsyncTask Class Reference
#coding
Public
♡ Eva Winterschön ♡

💡 Idea for a debugging script 💡

This might already exist for FreeBSD, and if so.. let me know!

- 1) keeps record of OS core/default settings: loader.conf, rc.conf, sysctl.conf, devfs.rules, login.conf etc
- 2) keeps record of file checksum on those OS core files (similar to the app, tripwire)
- 3) mode which shows divergence on current state vs known-default state in configs (1) and checksums (2)
-4) mode which tracks the files and their change-sets over time, similar to a zfs snapshot but at a single file-level

#freebsd#scripting#programming
Public *
Felix Palmen :freebsd: :c64:

I finally eliminated the need for a dedicated #thread controlling the pam helper #process in #swad. 🥳

The building block that was still missing from #poser was a way to await some async I/O task performed on the main thread from a worker thread. So I added a class to allow exactly that. The naive implementation just signals the main thread to carry out the requested task and then waits on a #semaphore for completion, which of course blocks the worker thread.

Turns out we can actually do better, reaching similar functionality like e.g. #async / #await in C#: Release the worker thread to do other jobs while waiting. The key to this is user context switching support like offered by #POSIX-1.2001 #getcontext and friends. Unfortunately it was deprecated in POSIX-1.2008 without an obvious replacement (the docs basically say "use threads", which doesn't work for my scenario), but still lots of systems provide it, e.g. #FreeBSD, #NetBSD, #Linux (with #glibc) ...

The posercore lib now offers both implementations, prefering to use user context switching if available. It comes at a price: Every thread job now needs its private stack space (I allocated 64kiB there for now), and of course the switching takes some time as well, but that's very likely better than leaving a task idle waiting. And there's a restriction, resuming must still happen on the same thread that called the "await", so if this thread is currently busy, we have to wait a little bit longer. I still think it's a very nice solution. 😎

In any case, the code for the PAM credential checker module looks much cleaner now (the await "magic" happens on line 174):
github.com/Zirias/swad/blob/57

#C#coding
ExploreLive feeds
About